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The GE Dartmouth Time-Sharing System is a new concept 
f the aa ;cmputers for problem solution. Now the users 
have com;. : : :°, ntro1 over their problems during the entire 
ttxerval ot prcolem statement through problem debugging 
and problem solution. This is in contrast to the previcmslv 
well-known batch data processing technique. P 

time-sharingk Time-sharing is the simultaneous use 
77 S h deVlce ? (Modd 33 or 3 5 teletypes in the system 

} M pe0p i e r. request,ng Use of a com puter for problem 
wlurion, problem defimuon. or problem editing. Such requests 

toIe™ce’o‘f U the D fH er 'S Ce 1 by “if com P uter svstera withhi the 
tolerance of the individuals at the terminal devices. 


t i 


teq°u f ir e S rim ' ; . im P omn « is (he complement of equipment 
iffi.-::* .ame-shanng system. A dual access disc 
must be ’ - -rn| la ^ Ulred - Tbe disc ( 18 million characters) 
(DATAN ET'Im iXT b0tl1 1116 colmnu nications processor 
tomniMm, ‘ ? d - mam P rocessor (GE-235) used for 
^«atd ? nr rUnnmg P roblems - T he disc provides access 
Sned moblemf am Th m H enn f atC reSultS ' and currently de- 
pams P for the c< ^ talns the executive pro- 

E the DATVSET w « ^ “ATANET-30. Available 

Wide* ET ' 30 IS a computer interface unit (CIU) which 


Bain processor T ng ? 01 ‘"formation flow with the 

3 «tem P °s 7t th n ‘ qUe ‘° 1116 GE / Dartm °t>th Timesharing 
;-<»inant “"tarns the 


trunanr *• — contains I 

«< teletype ^S^J ,I ? gram- D «P«ding upon the number 
DATAN F-' ? ,™. d to en ' er the system simultaneously, a 

A I6K. it !6K) ° r a D ATANET-30 (8K) can be uid. 
ttccutive d-™ £ T “ s P e< ;! fied because of the size of the 
Arsenti v iV 7^ ““ com P l er ’ 111(1 the running program. 
MK) and a nmlK Department in Phoenix, a GE-235 


1 riV 

•i 


* !6 &) and a DilSn Mfigf . in Phoenix, a GE-235 
»e capable beln f " sed : With these. 


: are capahle „ ■ al , c ueln B tiseti. with these, 

$W*ts) Soulh l- e r ng , f ° rty subsets (103A A T&T Digital 
«n be mldhrt whlch ° nI ,y one of any number of teletypes 
K&A subset^ dral-up capability is provided in The 


how'th et,Uipmcn t established, let me begin by telling 
the user constructs his nrohlem- 6 ' S 


^ ^ ^ user constructs his problem: 6 ' ‘“‘ S 

•§ ettinR the attention of the time-sharing 
. get a e. . - ' W1 ^ assume that the subset is a 103A. To 


, , -V w tudrt. X U 

teletype :;, j, one ; the user presses the ORIG key on his 

Priate n ,, m ‘-f na1 ’ and then proceeds dialing the appro- 
ve aamoer Ttm nnmh». _ . ° . >7 


. I uasuiUK U1C riUUlU- 

a-moer. This number corresponds to one of forty 
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subsets; and since these subsets are connected by rotary 
‘t IS necessary to remember only one number. When the 
connection is made, the user receives a high-pitched 

sssr ° lowed by thc printout ° f hu te ™ inai 


2. The user types HELLO, and follows this "greeting" to the 

chara^teri y Th nklng f the ^TURN KEY % nonprinting 
A user n,.mhl h ' S >' Stera , . then ask * f°r a USER NUMBER, 
f n U * 1S a Slx dl gtt number, or one alpha character 

characters^ for Trt t0taIIin « « u P ninttS pt ed 

Generaf^ ^r J? v i 0 " PUrp0SeS ' < In Phoenix, a t P the 

oeneral Electric Plant, a five-digit employee number is 

3E ir , b 7 3 sin S Ie alphabetic character whiS Sen 
tifies his work function. After this has been supplied bv 

S Sput b 6 v thJ URN w EY " depreSSed ' Note that fotlow^ 
| "P 111 by the user, he must press the RETURN KEY 

Fm 7he SS ySt T WiI ' a “ u P° n ^ information suppM 

that the RETURN m‘ S dlscussi °n, it will be assumed 

n .in: S har5 N is prcssed foiiowing user ^ 

TJmtch tbe „ RE TURN KEY is struck, a DATANET-30 

rioS as h eTthe 8 r reflt U r aVe P rogram acce P ts hoc of informa- 
■ a oroM-Sn, f reflectlv e input, an operational command, or 
problem statement. A discussion of these types of informa- 

and offering th? l^t f ° llowin S P a tagraphs Xre applicable 
ana ottering the least amount of confusion to the reader. 

3. The system next asks for the programming language in 

SYSTFvt 5 “Tt 7’A heS t0 state his Problem S by tySing out 
S\STEM- - ALGOL, BASIC, USP, DIP and FORTTiIn 

been^re^vedbT^' When the lan g ua gc specification has 
nIH „r KI d by he s y stem > 11 outputs NEW OR OLD? An 
old problem constitutes one which has been saved under the 
users individual number and can be recalled from the disc 

d P i^T n \n T re tha " 14,000 pr0gTams ma y be “ved on the 
and 're-ran P TO «™ m accessed from the disc can be changed 

recall ^nf S> 7 tem *? bus y when the “ser requests a 

Th an ° d problem, he will be requested to WATT 
The system then searches for the old problem at its first 

KTVd* X 5 RE k ADY - When tbe wishes^, 
ceail an OLD problem, he must give the correct name 

‘,md^ eC l Pr ° blera name “ «i ven for an old problem 

thr nrnhlX X user U number , the user is informed that 
tne problem has not been saved. 

If the problem is a new one, the user types NEW A 
new problem is one for which the user must specify a 
name and supply the necessary problem statements/ A 

^ Sh ° Uld be . named wi(b no more "Than si^ 
characters (spaces are considered as characters) All excess 

t ara n tt roblem I1 - be '° St - When bas b een e^ablifhed^ 

RFADV X 3 " ew ° ne ’ and tbe s y stcm has typed 
statt^rat hXT mpU 7 S ,. the mathematical model, using 
statement labels for each line of description. These labels 
must be numeric. If the line of type is preceded by a 

IoTeT X - y 1 Z° nS T U h d “ 3 P“ bIe m statement, i.e. 

, . Y + z - The system recognising this to be 

buffed smtement puts the statement into one of tiro 

thr d J S h eaCh) Wblle Ae fflled °nc is being put on 
the disc. Such storing of buffer areas is continued until 
the user has completed the statement of his mobtem 

Dla^tS 5 oVri? ^ for f subsets ’ ^ a hmit of 3,000 words 
r X on “ ze of the problem in the disc store 
s the user begins to type characters from the keyboard 
™ assembles the characters into words. If an error 

able d F.W F'k 8, c " are tWO method s of erasing avail- 
abie. Fust, the back arrow will erase a character (spaces ar e 

considered as characters) for each time the key is dep^ 

The back arrow pnnts on hard copy to aid the hot in 

roferen What A he h ™ sin Z and may P be preserved foTlatS 
ference. As stated, the back arrow appears on the hard 
copy; however the system makes corrections internal^ 
Aus, the erased characters will not appear if the pro- 
gram is listed. The second method of erasing is P th r 
depression of th e ALT MODE KEY which erases fn enrire 

vping DELETF e n ^ ^ ^ MODE KEY b Y 

typing DELETED The carriage return and line feed will 

be given automatically. 
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en the user has completed the problem statements and 
hes to run his problem, he types RUN. If no numeric 
abel precedes the line of information, the system con- 
ttues this as an operational command and ■ proceeds with 
ecution, if it is a legitimate command (if the command 
e F5- . n ° t , l e gih m ate, the system would respond by typing 
SVHAT? ). If the command is legal, it is run at the first 
P r“ y: “ d ’ if ^ s y stem is busy, the user is asked 
o ..WAIT. The system sets up a double level queue — 
requests are made from the remote terminals. 

Smce RUN is an operational command, it is typed with- 
t.a statement label. After the RUN command has been 
. the system will attempt to run the pro cram. 
^ e i.i D ^ TANET ' 50 ^ a hardware task list based* orT the 
ouble levei queue and informs the GE-235 to run the prob- 
em The DATANET-30 directs the GE-235 to the problem’s 
pcation on the disc via the computer interface unit. Prob- 
ans are distributed evenly over the discs in order to allow 
ter access At this point, the GE-235 further investi- 
gates the problem for errors in the problem statements and 
furnishes diagnostic information to the user if errors are 
bund. If the problem is free of errors, it is run with the 
djtta and results are printed back on the user's teletype. 

■ It may be interesting to note that the GE-235 will sort 
user statements and place them in numeric sequence. 

_■ Ifi the user receives diagnostic information after having 
«ed to run his program, he may change any problem 
Statement by typing in the statement label and a new prob- 
lem statement. This new problem statement supersedes the 
old one. To delete a complete statement, follow the 
eneration of a numeric statement label by immediately 
iepressing the RETURN KEY. This will erase the entire 
i/™™ ■ Lhe P roblem - Additional statements mav 
be added by typing in a statement label which is numbered 
^quenrially between the previously defined labels (i.e., 
00, 105 , 110 120 — the 105 statement label is the added 
gftement). * c ls for ^ reason the individual is cautioned 
fifcnumber his statement labels by a sequence of at least 
^n to allow for insertions. Please note that spaces are 
hot tolerated in statement labels. If, after a problem has 

J K Cd ' 6 “ S ? r Wants a LIST made - this is accom- 
phshed by typing LIST (without a problem statement 
abet, as this is an operational command). When pro- 
have been made, the user may request 
S er R y N ‘ If /“rther diagnostics are needed? the^iser 
informed, and the preceding steps mav be taken again 

hedced q out CC COntiDUes Until a P ro e ram is successfully 

toems ^ e th Pr ° bl a m f ha t bee " run ' the com P uta tion time 

toiriS ?f n Cn the ° Utput ’ There is no “use for 
wppse if this appears as “0” seconds. The computation 

imhT S , rou " ded off to tbe nearest 500 m seconds If a 
of rim? in 3 engthy °" e and squires more than a quantum 
k tW * USe f aJlotted °n the GE-235, this problem 
McmT Ji7i 3pPe l ° ff f ° r another problem. If no output 
ocm? «T- h i, ln quantum allotted, an audible sound 
ThTaS n ° tlfi ? ,he “ ser that his Problem is working. 
h?rt,? d b e f° Und 15 the result of sending RUB-OUT 
SS?J* er s to user’s teletype. 

m!. ** i P ro & ram been successfully debugged, the 
|! pro£rr y e eC . t - t0 Save il for a future reference. To save 
fi 18 nec , essar >' fo type SAVE. It may then 
riser d f any future date, as shown earlier. If the 

1 by ^typing 0 SCRATTH his . P ro S ram - he may erase 
vhen a nr^J CH and 11 ls automatically scratched 
urnniimH ' ,.,. L0 se quence is entered. The GOODBYE 

h^HFl rn" addltlon *? f ° rcin g the next user to entering 
nfeina n?, h SeqUenCe ’ ".f ° ffers other conveniences such at 
ioint Showin? f K aper r ° !. ‘° a place conven ient as a tear-off 
bnnect lme , the user leaves the terminal and dis- 

sipating the user s teletype from the digital subset. 

GENERAL DISCUSSION 

' e cj? pabiliti .f, s the user of the GE/Dartmouth Time- 
S >stem will find helpful may be mentioned: 

Mgrams U Tn Hnm catalogue list of his saved pro- 
ftg In the HELLO sequence, this can be done appro- 


priately when the system asks the user if he wants a new 
or an old program. If the user types in CATALOGUE, he 
• 3 ? s 8 ive “ a l“t of his saved program names. If, after review- 
mg this list of saved programs, he elects to run one, he 
types OLD and continues the HELLO sequence when the 
system asks for the old program name. 

2. If, after a user has begun to state a problem, he decides to 
give the problem a more appropriate name, he gives the 
operational command RENAME. The system will respond 
by asking for the new problem name. Satisfying this 
request with a six-or-less character name, the system then 
types out READY' when it is ready to accept additional 
problem statements. 

The preceding is an example of reflective input. Reflec- 
tive input is not recognised by the beginning characters 
of a line, but by the state of the DATANET-30 Executive. 
Reflective input is that information supplied by the user 
upon request from the DATANET-30. 

3. Included in the Time-Sharing System is a limited ability 
to manipulate entire symbolic programs, on other than 
a Jine-by-line or character at a time basis. 

These editing features allow a person to resequence his 
program to remove specified blocks of his program and 
retain other desired pieces, and to merge selected symbolic 
files into a single symbolic file. 

The command EDIT RESEQUENCE takes the pro- 
gram the user is working on and resequences it, sparing the 

If the P r °s ram is written in 
BASIC, the RESEQUENCE command will also update refer- 
ences to line numbers in the old program to match line 
numbers in the resequenced program. 

The command EDIT EXTRACT and EDIT DELETE 
are used to edit out large blocks of programs. As an 

100™T) ° ne might type the command: EDIT EXTRACT 

• T h iV? uld resu!t in ail of tb £ user's Progi am not 
included between the line numbers 100 through 250 being 
thrown away, leaving only the program block between 
these two numbers. 

The ability to merge programs allows a useT to combine 
a group of program segments saved under different program 
names into a single program. EDIT MERGE combines the 
named programs into a single program, and resequences it, 
making sure that no conflicts arise because of matching or 
overlapping line numbers within the named programs. ^An 
£ ^ a ™P e °i tde us e of EDIT MERGE might be- EDIT 
MERGE MAIN, SUBR1, SUBR2. b 

This command would result in the three saved pro- 
grams MAIN, SUBRI, and SUBR2 being combined into 

3 n SI ?!'?, pr0gram ' If the P ro ff rams were written in BASIC 
all END statements but the last would be removed. 

4. A general library is available to all users. This allows 
the dissemination and use of good programs that are of 
general interest These programs, although available 
to the user-public, cannot be changed permanently since 
the user is not allowed to SAVE or DELETE a 'library- 
program. A user may save a library program into his 
own personal library and then make alterations as he 
wishes. Library- programs are entered through a master 
teletype, of which there are only two data sets classified 
as master data sets and are not available to the public. 

5. There are certain commands v-hich can be implemented 
only from the master teletype subsets. The teletypes are 
uniquely defined by channel location in the DATANET-30 
so that commands other than those explained to the user 
are available to be acted upon. These commands allow 

mTiv t T r S i executive to be loaded into the 
uaj.anei- 30 and subsequently into the GE-235 Other 
commands allow a catalogue listing of all saved programs 
l rr of- P n " ted on a high-speed printer available to the 
t,E-_3o. An operational command called WARN allows 
messages to be printed on all teletypes in the process of 
usmg the system to notify them of any particular change, 
to the schedule for which the equipment will be available 
to the user. Presently the system is available on a twenty- 
four hours per day basis. 
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The queue used for the GE/ Dartmouth Time-Sharing is 
a double level queue. Level No. 1 Priority of the requested 
operational commands is as follows: 

Operational Command Priority 

OLD 1 

SAVE 2 

LIST 3 

INPUT 4 

RUN 5 

Level No. 2 — Run requests are processed on a first- 
come first-serve basis. 

A quantum is satisfied on the GE-235 by either the time 
allotment running out, the output area being filled, or the 
problem reaching a conclusion. Time allotments are in- 
creased depending upon the number of entries of a 
problem into the GE-235. These time allotments are as 
follows: 


Entry 
1 and 2 

3, 4, 5, 6 and 7 
REMAINDER 


Time 
2.7 sec. 
* -5.4 sec. 
10.8 sec. 


7. Background programs can be run while time-sharing is 
in the system. Additional study of central processor 
utilisation will provide more effective use of the computer 
configuration. Available, for example, is an operational 
command TIME, which gives the requestor central pro- 
cessor use percentage, idle time percentage, miscellaneous 
percentage, background percentage, and swap time percent- 
age 


These numbers are being studied to determine mo: 
sophisticated background configurations. 

Now that we have worked our way through setting up an* 
solving problems, the economics of time-sharing surroundin; 
the "waste’' of swap time may be discussed. Much discussioi 
has evolved around the inefficiency of having to swap pre 
grams in and out of the main processor at the condusif 
of a quantum of time on the main processor without consider 
ing the application philosophy for time-sharing. The length 
of problems run in time-sharing (2000 words maximum) tendl 
toward short run-time. Time-sharing has further created 
situation where previously written long problems have ?! m 
naturally segmented by the user into small programs 
ensure his control of design. Considering the technique 
time-sharing offers, there is a considerable saving in compuf 
time. If the problems come under the category of thf 
problems one might not want saved, then it is most prob$ 
that time-sharing offers a real saving in that preparation 
simple. There is no card punching and no waitfmSp’ 
around time for either key punching or computing, 
diagnostics are available to the user when he has sta. 
problem and it is fresh in his mind so that coirectio--^ 
possible to give faster debugging time, reducing costly req 
pilation of programs. Further, the individual is more 
to interpret the results to determine if the problem ^ 
correct for the physical phenomenon being investigaf 

Consider another situation where the individual?'-**; 
certain of the limits of parameters for the problem-,, 
time- sharing, the user has the facility of monitoring the bui 
results during the time the problem is being run.?-.? 
means that he can elect to stop the problem runnin; 
any time he wishes by simply typing STOP. (This woul- 
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HELL* 

DISC WILL BE RELOADED WITH 12/A TAPE AT MIDNIGHT TfNJGHT. 

USER NUMBER — P97495 
SYSTEM— BASIC 
NEW 3R OLD-OLD 
3LD PROBLEM NAME— PI 
WAIT. 

READY 

LIST 


PI 21:33 TUES. 12/07/65 

10 PRINT "PI BY MONTE CARL*" 

20 PRINT "N0. TRIALS", "PI" 

30 LIT 5=0 

40 LET C=0 

50 F8R 1=1 TO 250 

60 LIT X=RND( A) -. 5 

70 LIT Y=RND( A) -. 5 

B0 LIT D=Xf2+Yt2 

90 IF D>= .25 THEN 110 

100 LET C=C+l 

110 LIT S=S4-1 

120 SEXT I 

130 LET P=4*C/S 

140 PRINT S,P 

150 G8T3 50 

160 £N0 


RUN 

WAIT. 


PI 21:34 TUES. 12/07/65 

PI BY MONTE CARL* 

NO. TRIALS PI 


250 

3.152 

500 

3.176 

750 

3.16267 

1000 

3.116 

1250 

3.0848 

1500 

3.08 

1750 

3.11314 

2000 

3.112 

2250 

3.1 1289 

2500 

3.104 

2750 

3.09964 

3000 

3.108 

3250 

3.11138 

3500 

3.11771 

3750 

3.11573 

4000 

3.116 

4250 

3.10494 

STOP 


ST*P. 


RtADY. 



SYSTEM 

NEW SYSTEM MAH£--ALG*L 
READY. 

0LD 

0LD PR0BLEH NAME--GCDEUC 
WAIT. 

READY. 

LIST 


GCDEUC 22:09 TUES. 12/07/65 

100 GCD: BEGIN C0MMENT THIS R0UTINE FINDS THE GCD *F TW0 INTEGERS 
110 BY MEANS 3F THE EUCLIDEAN ALG0RITHIH; 

120 INTEGER X.Y,A,B,R; 


B: =ABS(X) END 
B:=ABS(Y) END; 


130 READ: REA DATA C INT£GERS,X,Y) ; 

140 IF X<Y THEN 3EGIN A:=ABSCY3 

150 ELSE BEGIN AtrABSCX) 

160 IF A=Q THEN G0 T0 PRINTOUT ; 

170 L00P: R:=A-(A\B)*B; 

180 IF R=0 THEN GO T0 PRINTOUT; 

190 A:=B; 

200 3:=R; 

210 30 T8 LOOP; 

220 PRINTOUT: PRINTt "THE GCD 0F“ “AND" , "",Y 
230 G3 T3 READ; 

800 DATA INTEGERS := 

900 78,43 

901 ; 

1000 END SCD 


RUN 

WAIT. 


GCDEUC 22:11 TUES. 12/07/65 

DARTMOUTH ALGOL. 

THE GCD OF 78 AND 43 IS 1 

END 9F DATA 
TIME = 1 SECS. 

CATALOG 

SAVED PROGRAMS, USER NUMBER P97495 
TUES. 12/07/63 TIME: 22:11 

PI C0NVRT LF-600 SVAN02 GCDEUC 

6.45L0 TRY SYNDIV 






PROBLEM MANE—CATLW***. 


system 

NEW SYSTEM NAME--ALG0L 
HEADY. 


NEW 

NEW PROBLEM NAME--R00T 
READY. 


IS 22! IS TUES. 12/07/65 

■'T~ INDEX T0 SYSTEM LIBRARY PR0SRAMS 

PKV - •- • 

(INNING LINE NUMBERS iF PR0QRAM CATEG0RIES: - 

050 TIHE-SHARINO USER INF0RMATI0N 
100 ENGINEERING/SCIENTIFIC 
s*800 MANUFACTURING . . : 

300 FINANCIAL . 

,i 400 EDUCATI0N 

i‘:500 OTHER (DATA PROCESSING, GAMES, MISCL.) 

DENOTES ALGOL PROGRAM 
. DENOTES PROGRAM THAT SHOULD BE 'LISTED- 

....TIME-SHARING USER INFORMATION 

+ INDEX TO SYSTEM LIBRARY PROGRAMS 
+ CURRENT OPERATING SCHEDULE INFO ON TIME-SHARING 
+ GENERAL USER INFORMATION, PROGRAMMING INFORMATK 
+ DESCRIPTION or EDIT RESEQUENCE, DELETE. AND EXTF 
+ DESCRIPTION OF EDIT MERGE COMMAND 


10 BEGIN REAL ESTIMATE, ANSWER, INPUT NUMBER, TOLERANCE! 

15 TOLERANCE :=10$-6; 

20 READATAC TELETYPE, INPUT NUMBER); 

30 FOR ANSWER :=INPUT NUMBER, (ESTINATE+t INPUT MUMBER/ISTIMATE)) /2 
40 WHILE ABSCESTI MATE -ANSWER), TOLERANCE DO 
50 ESTINAG-TE ::A!!SWERj 

60 PRINT (“SQUARE ROOT OF", INPUT NUMBER ,*=“ .ANSWER) ; 

59 END OF PROGRAM 

RUN 

WAIT. 
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DARTMOUTH ALGOL 


iCATLOG 

.STATUS 

INFORM 

EDITER 

MERGER 


SQUARE ROOT OF 2 


...ENGINEERING/SCIENTIFIC PROGRAMS. 

GENERALIZED X-Y PLOT ROUTINE 

STEEL BEAM SELECTION FOR VARIOUS LOADS 

DESIGN OF M-DERIVED LOW-PASS FILTER 

ENGR. E.P.A. PREPARATION. ’LIST - FOR DIRECTIONS. 

LINEAR REGRESSION 

LEAST SQ. POLYNOMIAL CURVE FIT. •LIST" 1-18 FOR 
NUMERICAL INTEGRATION 
POLYNOMIAL EVALUATOR 

* FINDS ROOTS, MAX'S, AND MIN 'S OF ANT FUNCTION. 

,. .MANUFACTURING PROGRAMS 

PROCESS CAPABILITY 

COMPUTES NEW MACHINE SAVINGS AND COST RECOVERY 
COMPUTES YEARLY AVERAGE UNIT COST 

..financial programs 

ARIZONA INCOME TAX 


D ■ . ..... 

tIXYPLOT 

4 BEMDES 
SLPFILT 
B ENGEPA 
O-LINREG 
t L5TSQR 
I INTEGR. 

5 P0LYN0 
t RO0TXY 


SAVE 

WAIT. 

READY 


CATALOG 


SAVED PROGRAMS, USER NUMBER P97495 
WED. 12/08/65 TINE: 12:05 

ROOT CONVRT LF-600 SVAN02 
6.45L0 TRY SYNDIV 

OLD 

OLD PROBLEM NAME — GCDEUC 
PROGRAM NOT SAVED- -GCDEUC 


f CAPABL 
LI VALUE 
f LEARNS 


•EDUCATION PROGRAMS.... 

• OTHER PROGRAMS.. 

400-LINE SORT ; PROGRAM TIMER 

600-LINE SORT PROGRAM TIMER (SEE - SO»T r X - ) 

RULES FOR RUNNING -SORTER' PROGRAM 
BATTLE OF NUMBERS (GAME) 

BLACKJACK (GAME) 

TIC-TAC-TOE (GAME) 

CALCULATES CUMULATIVE TIME FROM A SIVEM INPUT DATE 
-END OF SYSTEM LIBRARY INDEX 


FSOHTCA 
I SORTER 
1S0RTEX 
t'BATNUM 

I blkjak 
; Iictac 
IWEKDAY 


to determine more 


.When it was evident that the answers given i 
cable to the study being made.) The parame; 
tanged at any time the user wishes; once more, 
ttnputer time. Many programs in batch data 


ing produce large outputs of which only a small portion is 
used, but all of which was requested because in batch data 
processing, there is only one change at the computer before 
returning to the end of a lengthy queue. 


ough setting up and 
-sharing surrounding 
d. Much discussion 
aving to swap pro- 
r at the conclusion 
■-or without consider* 
haring. The length 
;rds maximum) tend 
.s further created a 
problems have been 
small programs to 
the techniqui ibat 
saving in cr- ict 
. category o i ;hooe 
it is most probable 
that preparation >* 
i no wait in turn* 
,r computing. The 
n he has stated hi* 
that corrections are 
ludng costly rccom- 
idual i* more abie 
e problem model ** 
ng investigated. 

individual not 
the prob.-.zG. **•;( 
onitoring the - olput 
being run. r™* 
•roblem running »* 

■ p. (This would be 
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jpTEMS PROGRAMMING AS A NEW TECHNOLOGY 
pSi'br two decades the field of computing and data processing 
gaslx'di lighted by the flashes of new' technological break- 
throughs and shaken by the long reverberations of reducing 
jhese to routine field practice. While this nourishing storm 
Ms -fry means ended, it has spread into new countryside 

gjndi I should like to survey this morning. 

HP®? enumerates the exciting new applications of com- 

| ^*~e.g. time-sharing computing, graphical display systems, 
business systems, information retrieval, pattern recogni- 
se 11 ? is struck by the extent to which these are, and will 
^ principally achievements of software technology. Such 
cations do not today await hardware inventions; thev 
f.’he perfection of systems analyses and systems programs, 
.a technology and a discipline, systems programming has 
sorely neglected. The literature is deplorable— few texts, 
eview papers, no common terminology, widespread ignor- 
ed loud rediscovery of elementary techniques. Formal 
iction is almost non-existent. Nevertheless, the past 
;e has seen impressive accomplishments in this fledgling 
ology. By extrapolation of present trends we can per- 
predict something of its future course. 

.systems programs we mean those programs which are 
led, to. supervise the hardware and make the information- 
sstng function available to the user in congenial languages. 
1,‘are distinguished, with some difficulty, from applications 
ams, which are designed for the solution of specific prob- 
WOc ' It is usual f G1 a programming system to have many 
opponent functions and programs built upon one another in 
Hjuntdal style. (Even application-oriented programs, when 
g|K, .inter-related, and growing, are today often called pro- 
BBgRiPg systems.) It is useful to divide the field of systems 
"Mpamming into programming languages, devoted to match- 
^the system to the mind of the user, and control programs, 
Hpealled ' executors, supervisors, or monitors, which schedule 
bu supervise hardware function and program flow. 


=I? CEDUR E LANGUAGES 

fSter' ^L firSt revi ® w P ro K ramrnin g languages. The first com- 
Summ!a St ^ m l made no concessi °us to the user. One pro 
■■ m blnar y absolute, or someone else got the machine 
■^T^velv " 3 Var , letv of algebraic languages, executed inter- 
TffKtii-- a PP eared - (By interpretation we mean that each 
statement is translated to machine code and then 
f y exetutcd : hence translation can be guided by the 
■ajjfev 0 Previous executions.) Thereafter, several pioneers 
1 ,, . compilers, in which the entire source program is 

° nCe lnto raachine code, and it then mav be executed 
Sjnever one wishes. 

- “ifciGOl mos j popular compiler languages are FORTRAN, 
"4^%,!,:-: arid c °BOL. All of these are procedure languages, 
i^Ntfems °£t StateS a ste P‘hy-step algorithm for solving his 
JwSntifir ' ' 1 " e . 1 two are algebraic languages, designed for 

tj^Pguapp ruputing. FORTRAN has been through four formal 
jSStanS 5!, IO , ns and has a score of dialects. It is undoubtedly 
fa Sf Wlde ^ ly-used procedure language and lends itself to 
g&r - dst compilers or efficient-object-code compilers. 


ALGOL, in its second language version^ is considerably mo 
general and elegant than FORTRAN, though somewhat mo 
difficult to compile into efficient object code. It has i 
standard input-output language, so numerous dialects exi 
Because of its generality and elegance, ALGOL has bei 
largely adopted by the international university conimunii 
1 his leads to difficulties, particularly in the United Stan 
"here the universities teach and publish in one language at 
the vast preponderance of other users, including the employe 
of our students, rvork in another. The mischief of this unhap] 
dichotomy has not yet ended.— 

COBOL was developed as a business language. In contra 
to FORTRAN and ALGOL, it recognizes the fundament 
nature of data representations as the essence of programmin 
and it provides varied and powerful tools for describing su< 
representations on media within and without the compute 
COBOL is cursed, however, by a painful verbosity and 
committee-generated collection of different ad-hoc solittions 
essentially similar language problems. 

While each of these languages has its deficiencies, their mo 
serious limitation is shared by all — the modem installatic 
usually has a mixture of scientific, commercial, and tex 
processing rvork, and this mixture wants a single langua; 
which can be used effectively on all applications. Towai 
this end SHARE, a group of users of large scientific computer 
and later GUIDE, a group of commercial users, combined wit 
IBM in 1963 to develop a second-generation procedure languaa 
called Programming Language/I. (Painful experience led tli 
namers to incorporate an index into the name itself.) 

Since I had almost no participation in this rvork, let ni 
identify myself as a PL/I enthusiast. This rear I have taugl 
it in three courses; next year we wall convert all courses to i 
We have a pre-release field-test compiler at the Triangi 
Universities Computation Center in North Carolina, and v 
are, after six tveeks of shakedown, beginning to get good con 
pilations and executions. I believe nothing approachin 
PL/I in thoroughness, carefulness, scope, and precision c 
definition has heretofore been undertaken in compute 
languages. 

Let me briefly restate the philosophical bases underlvin 
PL/I, as stated by Radin and Rogowav.i 

1. Anything goes. Being interpreted,' this says that the com 
piler should interpret and compile anv language statemen 
that is conceivably interpretable whether sensible or no; 
Statements are considered invalid only as a last resori 
This contrasts with good hardware design, where program 
ming errors should be caught as invalidities. The different 
is that in a compiler, one can both attempt an interpreta 
tion and give a diagnostic; in hardrvare these ate exclusivi 
alternatives. 

2. Anything you need is there. Interpreted, this says that thi 
language must give full access to the facilities of the hard 
ware and of the control program. A corollary follows — ; 
modern hardware-control-program complex has many func 
tions, requiring elaborate specification. Hence a procedure 
oriented language giving full access is a large and compli 
cated entity, when described in full. 

3. If you don’t need it, you can ignore it. This principle answer.' 
the problem posed above. Features, attributes, options, 
etc., can be omitted, and default statements assume the mosl 
common case. Keywords are not reserved. This means that 
subsets can safely and easily be taught and used; we have 
been doing this in class. It also means that PL/I pro- 
moters should publish some standard subsets for elementary 
scientific and business use. This has not been done. 

4. The language should be machine independent. This prin- 
ciple requires interpretation. It is true that PL/I reflects 
the structure of the von Neumann machine, and would not 
be ideal, for example, for distributed logic machines. It is 
vital, however, that the language be independent of 
arbitrary machine design parameters, such as the System/360 
allocation of eight bits to one character. While the 
language is machine-independent, any given implementa- 
tion will, of course, reflect the facilities of the hardware- 
very few implemented will elect to calculate binary floating 
point variables and decimal floating point variables as 
totally separate entities. Implementations of PL/I for a 
variety of computers is underway, and some language 
standardization effort has started. 



5. The general case must be handled; the common special case 
expedited. In FORTRAN, the language provided fast, neat 
ways of doing common, but somewhat specialized things. 
In ALGOL (and, somewhat, in COBOL) the language pro- 
vided for the general case, but gave no way to identify com- 
mon special cases, PL/’I attempts to provide full generality 
and also to provide identification, via the language, of 
special cases which the compiler can pluck out and give 
efficient peculiar treatment. 

6. A programming language is for programmers first. ALGOL 
is a publication language first; a printer listing language 
second. COBOL is a reader's language first, a writer’s 
language second. PL/ 1 was designed first as a coding-pad 
and listing language. It was proposed to follow that with 
a set of publication conventions and font-usage rules. This 
has not yet been done; it should be. 

At some risk of duplicating Mr. Currie’s paper to be given 
Friday, 2 let me now remark on what appear to be advances 
in language technology embodied in PL/I. Like COBOL, it 
includes explicit declaration of a variety of data types. It 
goes beyond COBOL in its character string flexibility, in bit 
strings, in array and structure handling, and in general 
mechanisms for controlling name scope and storage allocation. 
Going beyond ALGOL, it provides standard input-output, 
separation of name scope and storage allocation, and a host of 
string and supervisors' functions. Many Inverson-notation con- 
cepts and operations have been incorporated. One can specify 
processes for concurrent execution. One can set up conditions 
to be monitored for interruption. A major step forward is the 
provision of compile-time operations and variables, a true 
metalinguistic facility. 

It is necessarv to discuss character sets. By shortsightedness 
a decade ago, ' when FORTRAN was introduced, IBM had 
painted itself into the corner of two 48-character sets, differing 
in the graphics assigned to four codes. As soon as one attempts 
to do scientific and commercial work on the same installation, 
this becomes unlivable: the dual characters had to be sepa- 
rated. Given that at least 52 characters are required, one looks 
for a suitable font size. It developed that 60 characters best 
suited the diverse requirements of computers, typewriters, 
Scandinavian alphabets, keypunches, printers, etc. PL/I is 
designed to use this larger set for readability; a 48-character 
version is also allowed. 

I personally am convinced that PL/I can, should, and prob- 
ably will displace other procedure-oriented languages Over the 
decade ahead. This will depend upon the speed and efficiency 
of the compilers written. It will also depend upon the follow- 
through given instructional literature, sub-sets, publication 
conventions, etc. The computing fraternity will certainly be 
blessed if a convergence on one procedure-oriented language 
takes place. 

PROBLEM LANGUAGES AND GENERATOR TECHNIQUES 

Whether or not any such convergence in procedure-oriented 
languages takes place, a divergent trend in computer languages 
promises to grow rapidly. This is the development of problem 
languages, especially designed for specific applications, using 
the concepts and vocabulary already known by practitioners 
of that art, and often implying specific numerical algorithms 
and data representations under the syntax of problem state- 
ment. The civil engineering languages COGO and STRESS 
are prime examples; so is Mr. N. W. Bennett’s DEMON 
language for differential equations reported here on Monday. 3 
Several such languages have been built for specific commercial 
and information-retrieval applications. 

Such languages have many desirable features. They can 
usually be designed for computational efficiency. Most import- 
ant, they widen the applicability of computer techniques by 
adapting the hardware-software system to the very thought- 
modes of the highly skilled, but computationally naive, practi- 
tioner. No other move can so well overleap the training 
barrier that now impedes computer application. Hence I 
expect scores of such languages to come into routine use 
during the next five years. 

.This trend poses new problems for the language specialist. 
It is unlikely that computer manufacturers can muster the 
resources to develop scores of problem languages. Indeed, the 
users, more numerous and application-knowledgeable, have 
already pioneered this field. It is dear, on the other hand. 


that a general-purpose hardware-software system should includ 
the tools with which problem languages and their translators’ '■ j 
are fashioned. 

Fortunately, the technological tools and concepts for this I 

are at hand. Let us review the body of very powerful generator 
techniques whose unobtrusive growth has been somewhat over-'.' 
shadowed by procedure languages. 

A generator is a program that operates upon a generalizi 
skeleton program and a given set of parameters to produce. a 
specialized computer code. Examples in common use generate' 
sorting programs, control programs specialized by function or 
hardware configuration, and report-tabulating programs. Thd 
macro-assembly program is the best-known example, and we . 
will use one such to illustrate the techniques, which are by 
means new.* 

The basic technique is of course parametric substitution 
This has been generalized until the name, operation, operands,” 
and parts of these fields, can all be substituted, with substi-* 
tuted material being concatenated with skeletal material, other:,? 
parameters, or even a generation index to insure unique names • 
in the object code. Parameters may be specified in lists, in 
sub-lists with compile-time indexing, by parameter name 
(called keywords), and by defaults. Parametric substitution in? 
comments is not possible in this assembler, an oversight -iutfj?' 
an otherwise generalized system. 

The second technique is that of compile-time conditionals 
which govern the order of compilation. This mechanisnr™ 
includes conditional and unconditional compile-time branching 
compile-time statement labels, compile-time comments and's 
error diagnostics. Conditional assembly is not confined to y 
macro-definitions, it may' be used to control the order of com-, 
pilation of any part of the source program. 

Compile-time conditionals are greatly enhanced in power bf 
the availability of data attributes. This means that a symbol 
table must be built before generation begins, then augmented J 
after generation is complete. With this power, however, one 
can easily specialize object code to the data types of variablei| 
whose very representation need not be known until generation^ 
Compile-time variables constitute a facility of impressive? 
power In this assembler, they include numeric variables, bit? 
variables, and character strings. Given these, the generator 
user has a veritable compile-time machine with which; ..to 
cudgel his object code. The local variable, whose scope end" 
upon completing a macro definition and suspends upon, eiuei 
ing an inner macro, is useful; the global variable, existing. fo^J 
the entire generation, allows outer definitions to communicate” 
with inner ones, and allows independent skeletons of the same; 
level to communicate with one another. This global variable 
is very useful in building whole languages. 

A basic philosophical dispute arose during the definition of 
this macro-assembler. Whom does one favor, the detinitioi| 
writer or the call writer? To whom are things most natural® 

In scientific computing, call and definition are usually written, A 
by one man, and he wants natural definitions. In commercial^ 
practice, definitions are often written by the local priesthood^ 
and calls by peon programmers, who need natural calls. 
determined to favor yet a third class of user the ultimate u 
of the problem language built upon calls and definitions-. 

If one considers compilers for problem languages, certain| 
functions are rather independent of the source language. The”"" 
include symbol table building, data conversion, sequencm 
input-output management, subroutine library management 
and parameter passing to subroutines. Even source scan 
be somewhat generalized. These then are the obvious nine 
tions to incorporate into a problem-language building tool. * 
believe the macro-assembler well incorporates most of theses 
It is unquestionably true that one can compile more efficient 
object code with macro-generation techniques than by .w 
other high-level language method. It is also true today than 
compilation itself is slower. 

Not only speed-up, but also certain function additions "-aSjj 
needed if a macro-assembler is to be an ideal tool for budding 
problem languages. Most urgently, one needs facilities , m*. 
diagnosing abortive generations, endless compile-time loop? 
etc. Operand specification in calls should allow freer form » 


that, for example, infix operators might be used. User-defiribffi 
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data attributes, while difficult to implement, would be: 
useful. 
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If equal importance, we need generative facilities , for pro- 
SSng (1) documentation, and (2) test cases for a problem 
nguage. We need further development of notations and tecli- 
Quys. for specifying quickly and concisely the abstract syntax, 
ie. concrete syntax, and the semantics of a problem language. 
jc need experience and theory to give us rules for tiesigning 
jrbblem languages that are linguistically good — stable, not 
'"pr-prone, efficient, properly redundant. 
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NTROL PROGRAMS 

JMifeV-: -.-- - 

The most recent, most complex, and most promising part of 
ystems programming technology’ is that of control programs, 
hich supervise, allocate and schedule input-output memory 
wee, computer time and program flow. From early - times, 
istallations designed input-output subroutines to relieve the 
Itogrammer of the most burdensome and intricate part of the 
.. As the number and flexibility’ of devices proliferated, so 
instructions in input-output subroutines. The introduc- 
in' of the independently-programmed, concurrently-operating 
‘annel made an input-output program a necessity, 
input-output programs today handle device errors and 
tg, schedule traffic through channels, block many logical 
fjords into one physical record, manage alternating or cyclic 
Suffer schemes, and check labels. The most far-reaching recent 
‘eyelopments in input-output programming technique are (1) 
istallation library’ management, and (2) device-independent 
nogramming. The first of these is made economical by the 
fie of direct-access devices, such as disks. The second lech- 
Sque becomes needful only because of direct-access devices, 
ibrary management is a technique whereby all program 
erial and all data are organized into collections called data 
s:(or documents in the Atlas operating system). Each data 
^j’has a name, which may be long and compound. Any copy 
pf the data set on tape, disk, etc., has a label field, containing 
the name and format information. The control program keeps 
pet of catalogs, showing at any instant the whereabouts of 
ach data set, whether in core, on disk, on a tape reel mounted 
Ig^-machine, or on a tape Teel or disk pack in the instal- 
ition vault. The supervisory program is then able to manage 
“Hitting, filing, etc., for the whole installation. This will be 
rayenient for large tape libraries; it will be mandatory for 
mass, on-line storage, such as the magnetic strip files which 
old hundreds of millions of characters. 

Device independence as a concept is not new. For some 
^ars people have been writing programs which would accept 
input punched cards or card images on magnetic tape and 
Ktdtife printed output or line images on tape. The new 
ipment is that device independence can be achieved while 
each medium is used with formats, blocking, labels, etc., that 
ce natural for it. Further, device independence now extends 
•cross card readers, printers, tapes, disks, drums, magnetic strip 
lues, etc. Both the names of data sets and the types of 
devices containing them are specified to a program at job 
scheduling time via control cards. In practice, this means that 
^appropriately written commercial application can be evolved 
-^, ! !! disks or strips without reprogramming. 

,^This is achieved by a technical departure from input-output 
grams of the past, which were either interpretively executed 
ttm» £ 1 e l . coni P * |c d into the program at assembly or compilation 
. . ere th c specialized routines for getting or putting a 
‘ re “ ld are generated when the file is opened during 
i v , on * . This generation uses some parameters furnished 
i/h ■ , wnt?r of the problem program, some furnished in the 
ion cards, and some read from the data set label itself. This is 
_ el 7 useful function achieved by a very powerful technique, 

_ , 1 “O not believe the first implementations, which are 
“er slow, begin to exhaust the potential of this scheme. 

6 m .°. st dramatic development in control program- 
_S s ttie multiprogramming scheduler and supervisor, which 
tecfm.v, 3 * achl , ne to service many users concurrently. This 
Wstem« ’ barel y five > ,ears °ld, promises to bring' a new 
of concept to commercial applications and a new order 
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J“ g would so revolutionize scientific computing as multi- 
years ^ repredict that today, although recent 

With 1 glVe , n ? e ? more cons er v ative estimate of the speed 
jj* h technological revolutions occur. 

tionnf „ S ‘ C .. task . of , mosc scientific computing is the construc- 
: debuepi^ athema j 1C u 1 models ’ Therefore the task is essentially 
.V: SPng. one debugs the program syntax; then one debugs 


the program logic; then one debugs the model. Quite com 
monlv when the model is debugged, the problem is finished. 

Now progress in such debugging is a function more of the 
number than of the length of computer runs. Short turn- 
around time for many shots is worth more than many con- 
secutive hours of steady computing. Many installations today, 
however, have optimized the percentage of computer utiliza- 
tion at the expense of turnaround time, and less real progress 
per week is the result. One still sees one-shot-per-day instal- 
lations; in such shops able programmers can often get two oi 
three shots by late hours, eternal vigilance, and great craft. 
No one can assert, however, that such is the most productive 
use of able programmers. Short though hardware money be, 
most computer users are today more handicapped by lack of 
really able programmers than by lack of machinery. 

The problem of turnaround time is being attacked massively 
and frontally by Project MAC at MIT, a superbly financed and 
ably staffed effort to realise and demonstrate a new level of 
computer service and convenience. Corbato of Project MAC 
states unequivocally that their object is to achieve the desired 
service level first, and worry about efficiencies and costs when 
service goals are met. This approach has given rise to many 
new concepts, and stimulated others in counter-reformation. 

I do not believe, however, that the Project MAC approach 
should be followed by the general user, not even the general 
university user. It seems to me that the inefficiencies are so 
large and so fundamental that satisfactory cost may never be 
met, and that even the desired level of responsiveness mav be 
jeopardized. 

At this stage, all such judgements are a matter of opinion, 
and it will probable be the end of 1967 before data are avail- 
able to establish the facts of the matter. You should be 
warned, furthermore, that 1 speak for a small minority — most 
competent American computer scientists fall in the other 
camp. Nevertheless, let me detail many points of the MAC 
concept that seem extreme and give some indications whv mv 
colleagues of the Triangle Universities Computing Center 
have elected a quite different approach to the turnaround 
problem. 

First, let us begin with minor points. MAC assumes that 
programs are composed at the keyboard by the programmer. 
We believe paper and pencil are the ideal medium for the 
iterative and deliberative process of programming. Further, 
it is very clear that the professional kevpuncher can achieve 
better error rates than the casual user. Hence we ihink most 
programs should be written on paper, keyed by a professional, 
and entered. Then the debugging process should be conversa- 
tional and interactive. 

MAC proposes to examine each input character for syntacti- 
cal validity as received, responding to errors immediately. We 
believe this is a ridiculous computer overhead bringing verv 
little human-factor advantage. The end of each statement 
seems a proper place for syntax analysis. 

MAC proposes to execute high-level languages interpretively, 
as each statement is entered. We think it a far better bargain 
to syntax check statement-by-statement, but to do a compila- 
tion and execution only when the whole program has been 
entered or modified. 

MAC proposes to multiprocess, with at least two symmetric 
computers for ultra reliability. We feel that the dollar price 
of such ultra reliability far exceeds its worth in a university 
environment during this decade. Only a very few of the jobs 
must be done on time no matter what. These can be done on 
a radically cheaper computer normally used in peripheral 
service, provided the two are program compatible. 

Now to turn to weightier matters. It seems to me to be a 
gravely serious mistake to allocate time in fixed slices. This 
means that programs are stopped at arbitrary points instead of 
planned checkpoints. All of our experience with commercial 
applications shows arbitrary-point reruns to be much more 
difficult and far more costly than checkpoint reruns. Informa- 
tion measure shows us the same thing; at arbitrary points all 
must be saved, rolled out, and rolled back in. At planned 
checkpoints, the information content of memory is at a mini- 
mum, often several orders of magnitude below average, and 
the positioning of input-output devices is often immaterial. 
An alternate to time-slicing is rudimentary programmer disci- 
pline. You must put a checkpoint every n seconds, and vqu 
must call the supervisor when you reach it.”. This can readily 
be enforced by rolling out a program, without provision lor 
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rolling it back in. when n seconds have elapsed without a 
checkpoint call. We plan to attempt this approach at TUCC. 

From the time-slicing fallacy grows a serious complexity — 
dynamic program relocation via hardware. The argument goes 
as follows: We cannot hold all programs in memory. We time* 
slice to give good response. We have to roil programs out. It 
is certainly unacceptable to wait for roll-in until the same core 
space is available. (I have seen no simulation results, data, or 
even arguments results to support this conclusion anywhere in 
the literature. Some private simulation studies I have seen do 
not support it.) 

Therefore, so the argument goes, we must be able to relocate 
a program that has been stopped in midflight. The informa- 
tion is not available to do this compilatively as usual, so it 
must be done interpretively. That is dreadfully slow, so we ll 
do it in hardware. Various ingenious and expensive schemes 
for partly overcoming the inherent speed penalty have been 
proposed and are being built. The G.E. 645 and the IBM 
S/360 Model 67 represent two of these. In passing, I must sav 
that I regard the Model 67 as one regards his retarded child- 
one loves it because it is in the family, but one does wish its 
potential were not handicapped by its deformities. (These 
deformities are shared by all manufacturers’ "time-sharin®” 
models.) 

Seriously, let us consider fundamentals. Any dynamic pro- 
gram relocation scheme requires a table look-up between 
effective address calculation and memory fetch. This is on the 
critical timing path in any computer. Therefore one alwavs 
pays some time penalty for doing interpretively what should 
be done compilatively. Compilative relocations, furthermore, 
require substantially less hardware. 

The same compiler-interpreter argument applies to the two- 
stage dynamic relocation and segmenting schemes proposed by 
Dennis at M.I.T. and by Arden, Galler, O'Brien, and Wester- 
velt at Michigan.®. < Granted, one wants each programmer to 
have infinite name spaces. Only software techniques can, how- 
ever, yield infinite name spaces. The hardware techniques can 
only yield large name spaces, so these will be augmented bv 
software. More important, one needs to change the name- 
space-to-core mapping only when a program is loaded. The 
proposed interpretive schemes allow it upon execution of each 
instruction. This is one thousand to one million times as often 
as the function is needed, a difficult factor to buy back with 
hardware. I believe more real memory is a better buy than 
vast virtual memory in its effect on total usefulness. 
SIMPLICITY AND PERSPECTIVE 

Now for arguments even more debatable. With dynamic 
relocation hardware, the attempt seems to be to define the most 
complete hardware that might conceivably be useful, rather 
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D. FEX.XA : I would just like to ask Professor Brooks where 
was this perfectly adequate program that somebody was adding 
to. We haven’t met any perfectly adequate programs yet — 
people are always asking tts to add things to them. 

E- P. BROOKS: By adequate I meant an objective measure, 
and I think that probably each of us has experienced the task 
of having problem sponsors , or we ourselves, asking for minor 
refinements of function that, measured on the basis of any 
contribution to the total function of the organisation that we 
represent, mean that those^man-hours would have been far 
better used in tackling some more fundamental task. It was 
this that I addressed. I think there are a lot of adequate pro- 
grams. I have never seen a program in which everybody was 
satisfied with every detail, but that is different from adequate, 
and many times the pay-off function from most of our activities 
is built like this, and many times we are better to move on to 
another activity and get on the steep part of the pay-off func- 
tion curve. 
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than the simplest that might work. This is wrong philosonhv *^t- 
for any design. Speaking ethically and esthetically, I think the 
complexity of current segmentation— paging — relocation hard SMSF 
ware is, and I use the word seriously, ungodly. Speaking tech*"i& 
nically, I think this complexity will be self-defeating. ‘ 

The Stretch computer, at 150,000 transistors, and the Harvest’ 
computer, at 500,000 transistors, were mighty functional leans 
similar to those proposed today. Many new and useful tech 
nologies and concepts were developed thereby, and no partidr 
ants are ashamed of the results. We all learned, however f 
new respect for simplicity and restraint. I believe this lesson 
is about to be repeated. 

Furthermore, this same lesson must be learned by softwa 
practitioners. Programming is one of the loveliest of tfj 
creative arts. Like the poet and the composer, we work with 
pure raw concept, fashioning logical castles in the air with the- 
stroke of pencil on coding pad. This creative freedom brings 
with it peculiar temptations— to fuss over detail and to ova ' 
elaborate. Unlike the sculptor, the performing musician, or 
the computer engineer, we are not disciplined to simplicity 
and perspective by an intractible physical medium. 

This temptation strikes each of us in our profession™ 
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adolescence— we revel in the sheer joy of squeezing out ten 
instructions or tightening an inner loop by thirty micro:'* 
seconds. We rejoice in adding cute function after cute function 
onto our quite adequate programs. Adolescence is a wonderful 
age, and every programmer should go through it. Every pro 
grammer should also outgrow it into maturity. _r 

In maturity, every experience drives home the lesson of 'per- 
spective: the strategy of choosing data representations ant 
table structures, not the tactics used in coding, determine 
program speed and space. Every experience confirms that 
over-elaboration is the inherent temptation of our craft, th 
such elaboration is prideful, arising from our fallen nature,, 
and hence doomed, that true elegance lies in simplicity, and 
that simplicity requires the severest self-discipline. ’ 
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V- FINDLER: I would, like to refer to your statement on. 
Model 67. I understand it was a kind of brainchild of tfic 
University of Michigan team. How much influence have th. 
universities exerted in the architecture of the 360 system? % 
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F.P. BROOKS: Well, of the Model 67 — quite a bit. 1 think 
it reflects the work at MIT, it reflects work at Lincoln Labs 
and it reflects work also at Michigan, and there are two dip 
ferent models — the 24 bit model and the 32 bit model — because 
even the users couldn’t agree on the way they wanted dynamic 
relocation done. The basic 360 structure was essentially deter, 
mined with very little direct influence from the universities 
but a very substantial university experience, in that all three 
of the principal architects were people who had been profession ■ 
ally trained at PhD. level in the computer sciences, and it inis 
fairly rare ten years ago to find anybody faith a PhD. in Com 
puter Sciences. So that there was a good deal of experience « 
universities and of using university computers, and of course * 
good deal of familiarity with the literature. . ’*'* 


D. J. HARVEY: You have said that you would rather spen 
money on more core than on page relocation schemes arid s 
on. Considering the actual hardware cost of such devices,! 
appears that you can buy a page relocation scheme for some 
think like 4K words of core equivalent. Where do you thin 
the presumably hidden costs are in going to a page relocatio 
scheme ? »;■' 
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tjp. BROOKS: I think that perhaps there is some danger 
onfusing price and cost. If one weighs the amount" of 
gfdaiare involved in these schemes, and looks at it. or counts 
ransistors, it is clear that you can trade it for quite a fair 
mount of core. Even looking on a pricing basis , l personally 
elieve that many systems u-ith large numbers of users would 
eriefit more from having another 4K words of core, in which 
-it could perhaps leave some part of your system program 
Jident which you otherwise would not, or let another user 
ot get rolled out at all who would otherwise hai>e been rolled 
it*. I think overall systems response might be better. As I say, 
use things remain to be demonstrated with fact — we are at 
■% speculative stage at this stage. I would bet that way. 
yj. M. M. PINKERTON: 5 ou said at the start of your remarks 
hat there were certain /najor design objectives of PL //, one of 
thick was that it should be machine independent. May I ask 
1U if you think that the state the language has reached at the 
ament does render it satisfactorily machine independent? 

KIP. BROOKS: I don’t know the answer to that, because I 
ven’t tried to implement it on another machine, or on any 
Vhme. I do know that Digitek, who are implementing it for 
GE machines that are rather different in many basic 
vrameters — word length and character size — seem to be gener- 
—fy satisfied with the machine independence. 1 would say there 
is a greater danger at this point of PL/I being dependent on 
— rlain control program functions, than there is of being 
•pendent on hardware parameters, and 1 suspect that there 
is been less precaution given to that hazard. 

J. 'Af. WEADON: I would like to avoid getting on to too 
•de an area. Assume I have an effective system, I am con- 
rhed with efficiency, I am not concerned with relocation. I 
.Md like to refer to the article in Communications of the 
ICM for March this year in which a gentleman covered in 
imple terms, which I consider at least met your requirements 
^simplicity, the idea of programs and data being under read 
t*y controls , write only controls, read and/or write , etc. 
other than consider relocation, would you comment on 
ossible developments in this area with respect to the common 
programs on a multiprocessor device, common use of 
tbrpu tines, and interchanges between these different levels, 
Usably within the one system? In other words, the sub- 
!mes vary from a read only condition to a write only con- 
Itwn and so on. 

P/P- BROOKS: I personally am inclined to doubt whether 
lyte only is ever a very useful operating mode. Concerning 
y I was tiained by Howard Aitken — and he always 
. fi ? ve ?y stron S belief that all programs should be read only 
ml the time, and we have somewhat come lull circle from the 
friginai Aitken/Von Neumann debate on this point and we 
now store programs in the same space with data but we try 
best not to modify them. The ability to have separate 
Mection against writing errors and against read, and to have 
th tends of protection, is important. So I look for memory 
protection schemes to incorporate this facility as time goes by. 
indeed important and useful, and has been identified, to 
• _ programs which may modify themselves, programs that 
q serially reusable, that is they always initialise all para- 
•meters, and programs that are re-entrant— that can be con- 
whnT! y , USe , d without e ff ect - 1 believe that there is some- 
min t0 ° . recognition of the course of re-entrant program- 

hinat a !j m many - P ro £ rams Mat have large data areas and 
Wdain „ C °/ ° ne g , ains nothin S because you have to separate 
Ssli t a t'**? lh eac ^ user anyway, so all you gain is the copying 
M rnadr-t code and mi ght have been better to have 

• of it r , S u-u y reusa bte, shorter and provide multiple copies 
l enL u* ° ne °f. lhe ma, ° r tasks f aC!n e compiler writers is 
hW/,, how to write efficient re-entrant compilers that will 
re - entrant c od e. This is a non-trivial job 
(t thath! m whlch , V er y. httle progress has been made. I think 
that T ^ C mac ' llne installation will have many things in it 
f| time a y cc-eritrant, and I think that we will have to have, in 
gjzZ-i a>m J nler j lhat mill produce re-entrant code, and that a 
t' ftatus ro . utlne wlU move back and forth from read only 
%/Khcrr c ?Py- lnl ° being used in read write memory 

tjPror,JL may be sub i ect modification, for example in the 
.. °f generation. Does that answer your question? 


J ■ L- COOK: I have two questions— firstly, would you please 
comment on what you feel is required in systems programming 
for a hybrid installation, as against PL/I which I believe to 
be more for pure digital systems? Secondly, could you please 
comment on the EAI 8400 dynamic memory relocation as 
against, say, the GE and the IBM 360 ones? 

F. P. BROOKS: I am not familiar with the details of that 
scheme— I have never studied the manuals so I cannot really 
fruitfully comment on it. I think most of the remarks 1 have 
made concerning the interpretive rather than the compilative 
nature of dynamic relocation apply to any dynamic relocation 
scheme. Some of these penalties are inherently built into the 
fundamental way you tackle the problem. With respect to 
hybrid computation I think that we can expect the problem 
languages to be more successful than procedure languages here 
generally, because of the suitability of the analog equipment for 
handling differential equations and for their peculiar suit- 
ability for that sort, of work, and so I expect that a hybrid 
system will have a control program that is really in no way 
different from a general-purpose control program , but to have 
language facilities that are more problem-oriented. 

M. KOYARIK: I would like to refer to the choice of inteival 
in time sharing, that is the choice of intervals at which the 
program is dumped and space made in memory for the next 
programmer. The speaker has shown a preference for a dis- 
cretionary interval, lhat is for the programmer to decide him- 
self when he wants his program dumped and make space for 
the next man, as opposed to the MAC preference for a com- 
pulsory interval. I wonder if it would be possible to qualify 
this preference. It appears to me that in a real life environ- 
ment, most runs don’t have the result the programmer intended 
in the first place, and it takes a lot of development to get them 
there. Under such circumstances it appears to me that the 
MAC scheme is preferable. It. stops the system before it gets 
too far into error , and does not dump a programmer who may 
still have some hope of getting the result in the next slot of 
time he gets. 

F. P. BROOKS: Two things — one is that 1 have no disagree- 
ment with anybody over the question of how long the interval 
should be when one programmer has the machine consecu- 
tively before it is switched to another. This is a parameter 
that I think we are all going to determine by trial and error. 
It is said to be true that if you have a light switch, and the 
light is connected to the switch on your left hand, and you 
have another one on the right hand in which the computer 
senses the way you throw the switch and then sets the light, 
then if the computer can respond in 100 milliseconds you can’t 
teU the difference between the left-hand and right-hand switch 
behaviour. This means that one would like to be able to ser- 
vice, say , 100 users at a time with a 100 millisecond kind of 
response. This means that you should have a one millisecond 
slice— and nobody can afford that at this point because of the 
high overheads. Most people are planning something of the 
order of a half-second to a second kind of interval. Most 
people that are today operating are operating with substantially 
longer intervals than that. I know that at MIT they have 
moved from one second to two seconds and 1 believe they are 
now at four second slices. My argument bore more on the 
question that I would be happy to roll a programmer out and 
toll him back, and roll him out and back in as many times as 
he wants to, in exactly the same way MAC does, except that 
I would like to impose the discipline of expecting the pro- 
grammer to teU me what a good time to do that is, and assume 
that some time in the length of time I am willing to give him 
anyway he will hit a good time — for example, when he is about 
to call a new program or when he has fust finished writing an 
output record and the point I am making is that the informa- 
tion flow at such times is orders of magnitude lower than it is 
at arbitrary times. And there are big chunks of efficiency that 
can be had, provided such a discipline is livable— whether it is 
or not, once again remains to be determined, and I don’t know. 
But I don’t really propose that, we just roll people out and 
leave them out. I propose to do that only as a disciplinary 
measure when they refuse to tell us a good time. 
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SUMMARY 

Much of the difficulty in using digital computers arises in 
the area which can be described as the communications inter- 
face between the computer and its job environment. This 
area is discussed as two separate interfaces, one between the 
computer and its programmer, the "instruction interface"; and 
the other between the computer and its data environment, 
the data interface". 

The advances made in improving these interfaces are dis- 
cussed. The instruction interface has been improved over the 
years by the development of Assemblers, Interpreters and Com- 
pilers. .More recently however, multi-user time sharing systems 
and their associated software have given a dramatic advance. 

The growing number of real time computer applications in 
science and industry are discussed, followed by some com- 
ments on the characteristics of these real time data inter- 
faces. A vast new area of application is beginning to emerge 
for these real time systems, in which the computer is inti- 
mately connected into its job environment and is therefore 
able to bring its full speed and versatility to bear in many 
new places. 

Introduction 

One of the biggest difficulties in making effective use of 
digital computation, has been the poor inter-communication 
between the computer and its problem or job environment. A 
better awareness of this difficulty and some recent significant 
improvements in the means of communication with computers, 
promises a great advance in their usefulness. Many of the 
valuable functions we imagined computers would do for us have 
been largely frustrated by the clumsiness of the interface be- 
tween the computer and its job environment. Although a 
great deal remains to be done, some valuable groundwork is 
behind us. 

The objective of this paper is to point out the “interface” 
problem and to describe some of the new advances being 
made in its solution. 

Two Interfaces 

The computer can be thought of as having two interfaces 
between itself and its “information” environment. Firstly the 
"data interface", through which the computer receives its raw 
data and returns its processed results. Secondly the program- 
ming or "instruction interface”, through which the computer 
receives new programs of instructions and returns indications 
to the user of its current progress through the calculations. In 
many cases, exactly the same I/O equipment is used for both 
purposes, however, their separation makes it easier to see the 
problems. 

The above distinction is perhaps made a little clearer with 
the observation that the major attention to the instruction 
interface until recently has all been in software development 
(e.g. compilers). Hardware development at both interfaces (e.g. 
multi-user time-sharing systems aqd inexpensive real time com- 
puters) now make possible some very significant advances in 
the computer industry. 

Data Interface Developments 

The earliest computers had very simple input/output hard- 
ware, generally a paper tape or card reader and punch, and 
more recently an output printer. The data interface to com- 
puters of this type, which includes most of those in Australia 


up to the present time, has quite large time lags, necessitated!^ 
by the manual operations of data checking, editing, punching’ r 
and verifying. 

Some of the most interesting computer applications cannot**'* 
be attempted off-line through this cumbersome tape or caid! 
interface. Of course on-line systems have been with us for’ * 
some time, not only in the military and space environment: 
however, the comparatively recent development of fast, but ini? ^ 
expensive, “real time” computers and of time-sharing com- 
puters, has opened up the application horizons. As a result?! 
of these developments, many existing "general purpose” coin.?*' 
puting centres will be severely “dated,” and the world’s com-" ' 
puter population can be expected to lean much less heavily fa 'IS ;• 
the direction of business data processing systems, with the* 
appearance of many new kinds of industrial and scientific* : 
installations. 

These new applications and the characteristics of the data? ^ 
interface necessary to handle them, will be discussed later./.:;!)?!! 

Developments in the Instruction Interface 

The very early computers were programmed in machine Ian-’ 
guage or in simple assembly languages. The difficulties of in-! ■ 
structing a computer in these languages lead, in time, to-ffi^S 
development of some very effective interpretive schemes which ' " 
were relatively easy to use and debug. UTECOM (English-* 
Electric Deuce) for example, at the University of New South ’ ' 

Wales, had a powerful matrix interpretive scheme “GIPl” 

an<l a mathematical formula interpreter “GEORGE2”, which|a&v 
together accounted for most of the programming originated?®! 
on that computer over many years of operation. 4 

With the development of larger more expensive compute 
the hands-on debugging techniques generally provided wi 
interpretive systems fell into disfavour, and compilers such". 
Fortran and Algol displaced interpreters in the instruct^ 
interface between computer and user. Although this develop 
ment made the computer more efficient at productive computing 
it introduced some complications into the instruction interface 
which have only recently been overcome. Firstly, the computet 
no longer took the programmer’s original instructions one a¥ 
a time to obey them, but instead translated the whole progran 
into something quite different prior to run time. ' Secondly, -.thi 
user had no real time contact with his running program, anc 
had to do his debugging on the basis of feedback from prin 
outs of intermittent diagnostic runs. For users who Work 
entirely at, say, Fortran language level, many compilation 
were often needed before a working program was produced 
These difficulties with the instruction interface are noy 
course, greatly reduced, with the development of multi-u 
time-sharing systems. Pioneering work at MIT3 4, BBN& 

1962, lead to the manufacture in 1964 of the first comput 
specifically designed for multi-user time-sharing. One of th< 

PDP-6 systems, operational at the University of Western 'At 
tralia, since May, 1965, provides a real time hardware and soi 
ware interface for eight simultaneous users. Seven of/i'tS ’ 
are located about the University campus and at CSIRO, Wl 
the eighth line can be switched into the PMC’s telex netw.or 
thereby making the computer accessible to a user almost an 
where in the world. This remote telex user station is operate 
experimentally into Perth with the co-operation of the Unive 
sity and the PMG’s Department, and was demonstrated .&$ 

North Sydney a few months after installation of the system! 

1965. The record to date is its use by DEC engineers, /a8 
programmers from near Boston, on the other side of tht jybrld. 

These time-sharing systems retain the advantages ofyconfg 
pilers, but re-instate the intimate user-computer interaction,- ajg 
debugging time. Interpreters are also reinstated, particulig® 
for small calculations and one-off jobs which previously woulu/^ 
not have been worth using the computer for. , ■ 1 

The instruction interface now provides the following: 
tics: 

’ _ . . 

Source languages program and corrections (e.g. • assembly^ 
or Fortran) may be keyed directly into the computers! 
mass store from a remote user station using an - 
programs. 

* Compilation and assembly can be initiated by the . J 

grammer from his user station, on which diagnostics^* 
be printedS.' : 

* The assembled program can be loaded and run untfci® 
diagnostic control again from the user station, and'assenttS 
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bly language corrections made as the errors are located. 
(This does not correct the source language version, of 
course?.) 

’ interpretive language programs may be typed in directly 
From the user station and obeyed, with results (and diag- 
nostic) returned immediately to the programmer, e.g. vari- 
ous desk calculator routines and the JOSS system. 

■' library programs and filed copies of user programs can be 
loaded and run under control of the remote user with a 
-very minimum of computer centre red tape, once the com- 
puting and storage capacity is adequate for the number of 
users. 

It is interesting to note that the usefulness of on-line pro- 
gram editing, debugging and interpretive desk calculator soft- 
ware is not necessarily limited to large time-sharing systems. 
At least one manufacturer (DEC) has provided these facilities 
on all its systems down to the smallest, in the interests of sim- 
plifying the instruction interface between the user and his 
rcmouter. 

7 jction Interface Hardware 

„A,e hardware used in this instruction interface has most 
:ominonly been the American Teletype, with or without the 
Hunched paper tape input/output option. This generally 
operates over a single pair of wires in half duplex mode (it 
:an be full duplex), and is the standard T1VX teleprinter used 
n the U.S.A. It is also used in Australia over private lines 
md requires a 110 baud channel (10 characters per second), 
rhe character set is limited to the decimal numerals, the upper 
ase alphabet, and about 26 special symbols. It is an 11 unit 
ode with eight information bits per character, conforming 
o the present American Standard Code for Information Inter- 
h-'.nge (ASCII). It has no parity bit. 

operation over Australia's public telex network and be- 
Australia and overseas, the Siemens 100 teleprinter (again 
l,r without paper tape) or its equivalent, operating at 50 
laud, has been used (6 characters per second). This is a half- 
uplex system with a 74 unit code containing five information 
its per character (no parity) and giving the numerals, upper 
ase alphabet, and 15 special symbols. It is, of course, more 
estrictive than the ASCII code, necessitating frequent letters 
nd figures shifts, and the use of two characters for some of 
he ASCII special symbols. It is, however, quite effective. 

The operation of a 100 baud teletype over the public Tele- 
hone network (rather than telegraph), using an error correct- 
ag modem system, should be economical to operate although 
• —.itial cost would be much higher. 

uacter display and keyboard units are being considered 
- of teleprinters at some centres. Provided they are 

gated near the computer or are connected over a large band- 
idth channel, they' can give a very much faster output from 
-- computer than is possible with a ten character per second 
eietype. They are probably more fun to use, however, the 
bsence of a sequential printed record of the programmer’s 
conversation” with the computer may limit its usefulness in 
le instruction interface. 

A full scale CRT display with point, vector and symbol plot- 
ng facilities and a light pen. has distinct possibilities for the 
agination and examination of programs at flow diagram level, 
computing centre at the University of Western Australia 
itiated some work in this direction. The facility requires 
■ bandwidth connection to the computer and is generally 
writable as a remote station. 

Peripheral equipment manufacturers and research groups 
ue and overseas are aware of the neeed for better remote 
ier equipment, and along with the advances in software we 
n still expect some new equipment for computer-program- 
er communications. 

sal Time Data Interface Applications 

The digital computer’s processing speed is prooably its major 
Fet To make effective use of this speed, however, it is often 
cessary to connect the computer Uirectly into its data environ- 
ent - Some of the application areas where this has been done 
''stully are now summarised. 

- ".tine Data Collection: Nuclear physicists were among the 
to realise the advantage of a fast general purpose com- 
ber over fixed purpose analysers, in the collection and pro- 
* ln g of experimental data arising from nuclear reactors, par- 
!e accelerators, etc. They were interested in building up stati- 


stical distributions (histograms) of particle energy or tune-of- 
flight along a measured path, and in processing these distri- 
butions. Particle detectors are connected onto the computer 
via a pulse height to digital converter and for each particle 
received, the computer updates the frequency count for the 
corresponding energy or time. Particle energy or time are 
separated into several hundred different levels (channels) to 
give adequate discrimination, and manv thousands of particles 
are processed in a run to give significant distributions. 

These nuclear multi-analyser computer configurations gener- 
ally also include two buffered digital to analog output conver- 
ters, driving a precision CRT display. This display gives the 
experimenter a look at his results, both while the data are 
being collected and during analysis. By this means he has an 
immediate indication of a faulty experimental set-up, and 
during the analysis phase can select his analytical technique 
to best suit the distributions his experiment has produced. 
Computers used for this work must have a very fast reaction 
time, since they are required to process data arriving at inter- 
vals of only a few microseconds in extreme cases. 

Another research group who are enthusiastic real time com- 
puter users are the experimental physiologists, particularly 
neurophysioiogists. In 1962 a special Laboratory Instrument 
Computer (the LINC) was designed at the Lincoln Laboratorv 
of MIT, and built at many research centres from Digital cir- 
cuit modules. It was a small general purpose computer, with 
input/output equipment especially designed for collecting and 
processing biomedical data. The same work can now be done 
on commerically produced computers, although these at pres- 
ent lack the enormous LINC program library. Some of the 
most common applications involve the time averaging of tran- 
sient responses, to extract the response signal from a much 
higher let el background noise. Typically, a biological organism 
is stimulated hundreds of times and the corresponding responses 
averaged out so as to suppress the random noise and enhance 
the consistent signal. Another common example is the auto 
and cross correlation of biological signals (for example, electro- 
encephalograms), to determine time relationships, with subse- 
quent Fourier analysis to determine frequency components and 
phase relationships. This type of work has been in progress 
using the PDP-5 at the University of New South Wales, since 
July, 1964. 

Typical biomedical configurations include a fast analog to 
digital convener, connected to several analog signal sources 
via a computer controlled multiplexing unit. The computer 
samples the analog signals, converts and reads in their digital 
representation for processing. The sampling rates available 
can easily keep up with the typical biomedical waveforms 
which are generally no more than a few thousand cycles per 
second. These installations also include precision CRT dis- 
plays, which are used to give pictures of transient responses, 
correlation functions, frequency spectra, etc. In many cases 
the results are simply recorded photographically from the 
CRT tube without a digital printout. 

Other research groups using computers in this way include 
psychologists, who not only input and analyse data with the 
computer, but use it to produce the stimuli to which the sub- 
ject’s response is being measured. This has the added advan- 
tage that the computer can adapt the stimulus to the subject’s 
response, for example in an investigation of the subject’s learn- 
ing characteristics. Oceanographers are a relative newcomer 
to the field, but already several small computers have been 
taken to sea for the purpose of pre-processing submarine data 
as it is collected (temperature, salinity, sound propogation, 
etc.), to minimise the possibility of collecting nonsense data 
due to instrument faults which might otherwise go unnoticed 
for long periods of time. 

In all of these applications one of the major reasons for using 
a S enera l purpose (programmable) computer is to have the 
flexibility to adapt the data collection and processing system - 
to the changing needs of the experimenter as his investigation 
proceeds. Re-programming may be tedious, but is generally 
much easier than rebuilding vour special purpose hardware, 
which was perhaps already at the extremity of its capability. 
Many programs are now available for this type of work, for 
example nuclear multi-analyser, auto and cross correlation and 
data collection (e.g. DATAK system) routines for PDP-8 real 
time applications, which reduce the work necessary to get a 
computer based data collection system operational. 
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Instrument. Control: Instruments used for checking the 
characteristics of manufactured products or analysing the struc- 
ture of unknown material often involve the application of a 
sequence of actions and the analysis of the corresponding re- 
sponses. Many instruments in this category are now being 
fitted with computer control, so that test sequences can easily 
be changed (e.g. for a different product), human operator 
intervention kept to a minimum, and processed result reports 
typed out rather than a simple indication of the raw measure- 
ments., Among the instruments of this type are X-ray diffrac- 
tometers (for molecular crystallographic studies), mass spectro- 
meters (for chemical and isotope analysis), non-destructive com- 
ponent testing (e.g. circuit module production line tests), des- 
tructive testing of samples from a manufacturing process (e.g. 
controlling an Instron textile or fibre tester), and many others. 
A closely related application is the hybrid computer in which 
the digital computer not only controls the analog computer but 
shares with it the computation task (e.g. differential equations 
to the analog, algebraic equations to the digital). 

In these applications, the computer is not only collecting 
and processing the data, but is also controlling its generation 
by controlling the associated instrument. By largely eliminat- 
ing the human instrument operator, a much higher throughput 
and more consistent result is often possible. The results are 
analvsed and processed to the point of producing a typed re- 
port! free from any arithmetic errors. 

Systems of this kind operated to date in Australia include a 
mass spectrometer and an X-ray diffractometer at the Univer- 
sity of Western Australia, and an AD-80 analog computer at 
the University of New South Wales. 

Message Processing Systems: General purpose computers have 
been used for some time at the centre of message switching 
and processing systems. Most of these process serial telegraph 
signals and the relatively slow data rates are much simpler to 
handle than other real time applications. There are, of course, 
sometimes difficulties with message interpretation and storage 
and retrieval of message data, which necessitate a large instal- 
lation. The communications interface can, however, be handled 
for over 100 lines by a quite small fast computer. 

The interface equipment converts between line currents and 
computer logic levels. Each line has a receive buffer of at 
least one bit. Since bits arrive at the maximum rate of 50 
to 100 per second on any line, a 100 line unit allows the com- 
puter up to 100 or 200 microseconds to process each bit re- 
ceived. The amount of processing can be cut down by buffer- 
ing a whole character (up to II bits) at the interface, however, 
this increases the cost of the hardware and the tendency is to 
do as much as possible by program. 

Apart from their application in normal telecommunications, 
message handling computers have been used on many of the 
time sharing svstems to provide the multi-user communications 
with the central computer. Although this job can be handled 
by some of the large time-sharing computers, the small satellite 
computer provides an attractive approach by relieving the cen- 
tral machine of some of the trivial character processing, which 
it can do little better than the small system. 

Process Control and Data Logging: These applications are 
beginning to make progress after what seemed a rather shaky 
start. Reliability requirements are generally extreme, and 
manufacturers are now offering dual computer systems to 
solve this' difficulty. This is not surprising since the computer 
cost has become the smaller part of the system cost. These 
installations often have quite elaborate input/output facilities 
which enable the computer to "watch” the manufacturing pro- 
cess, print out a performance log, give the alarm on abnormal 
conditions and in control situations, manipulate the plant con- 
trols to give specified performance, to start up or to shut down 
the plant. 

Typical interface equipment include^ low level (millivolt) 
analog multiplexed inputs and higher level (milliamp) inputs, 
all of which are sampled one at a time at several second inter- 
vals and fed to the computer via an analog-digital converter. 
Other inputs include pulse trains (e.g. from turbine flow 
meters), contact closures (indicating the condition or position 
of plant), and manual settings (set points) specifying how the 
plant is to be controlled. Computer outputs include logging 
and plotting of plant behaviour and signals to actuate control- 
lers, e.g. pneumatic control valves, electric motor controls, etc. 
Since outputs are discontinuous in time, the computer having 





to divide its attention between many different functions, ea 
output is buffered by a register (generally of flip-flops), ffifi 
which the relays, digital-analog converters, etc. are operated' 7 
An interesting blast furnace control system using a PDP- 4 /SSS 
eludes a computer controlled audio tape recorder and pu 
address system, by which the computer advises operating gj 
selectively at different centres of its intention to alter o 
ating conditions in their areas. ' 

Real Time Interface Characteristics 


The above applications represent only a short list of the 
time jobs now being performed by general purpose compu 
The processors of these computers are not very different 
those used for business data processing, except at the inte 
they present to their job environment. Two character^ 
predominate; a fast reaction time and equipment Hexibiity. 

Interrupt System: For the computer's processing speed to? 
put to good advantage the computer must remain alert td:it*i 
environment and be in a position where it can react quit 
to significant external changes. This is generally achieved 
the hardware facility of "program interrupt.” By this m 
the computer has its attention taken away from what it. 
doing. That is, the current program is suspended, the posi 
of the break point is temporarily stored in memory, and 
computer starts performing an "interrupt routine” from.*® 
special memory location. This interrupt routine identifies 
external signal, takes the necessarv action, then retums i 
trol to the original program at the point where it broke 

Absence of this simple facility prevents many of the o 
computers from working effectively in real time. A comm 
approach on these older systems (used in controlling ttii 
readers and punches, etc.) was to either stop the procest 
completely, waiting for some external event (e.g. card read 
or to have the computer wait in a loop of a few instructs 
repeatedly testing for the external signal to appear. Althob 
interrupt systems come as a bit of a shock to uninitiated p 
grammers, they are an important part of real time proc 
in all but the simplest applications. 

If there are several different external devices which may int 
rupt the processor, it is usual to arrange them in some'w 
of priority sequence such that higher priority inputs may inti 
rupt the interrupt routines of those of lower priority.’^ 
can easily be programmed, however, as the number of,® 
sary priority levels increases, the hardware priority _mt 
becomes more desirable. 
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Typical reaction times to a program interrupt request^ 
several microseconds, followed by at least another 1ft. 
seconds to process the interrupt. While this is adequ 
many situations, a faster system is sometimes necessary, 
is generally done by adding extra hardware to perfox. 
simple control functions necessary to input or output the 
increment a memory location, etc. The reaction time can^ 
be a few microseconds, followed by a few more mi 
to process the interrupt. This is the “data interrupt’*;*! 
used to input high-speed nuclear data and the “cycle stes 
method of block data input output, used by most new? 
puters for handling magnetic tape, discs and drums, and 
speed displays. T ransf er rates can go up to one word 
one or two microseconds with existing machines.-. m 
the “data interrupt” requires more hardware, it reduo 
load on the processor for a given I/O data rate. Ji/pH 
I/O Equipment Flexibility: The early computers gen 
had one input and one output device. By contrast,,® 
computers have capacity for dozens of devices or grpu 
devices, all of which can often be operated simutanepusl) 
High-speed equipment, transferring blocks of data aW 
than one word every fexv hundred microseconds, geni 
uses a “data interrupt” facility directly to or from core:®? 
Slower devices such as cards, paper tape, printers, -® 
initiating controls of fast block transfer equipment, 
use the “program interrupt” facility. , For handling largely 
bers of teletype lines, or analog input lines it is usual. .®, 
a program controlled hardware multiplexer, which sea 
multitude of lines for interrupts or data transfers. *S8( 
Many new I/O devices have appeared recently to mat] 
computer better to its job environment, particularly^ 
business data processing and general computing field, ar 
more can be expected. However, some of the fronti 
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on new computer applications requires the flexibility to connect 
almost tiny information source or “sink” onto the computer. 
A few manufacturers specially aim to have their equipment 
used in pioneering these new applications, and provide not 
onlv computers with conventional peripherals, but also the 
information and equipment necessary to connect arbitrary in- 
put P ut equipment to their systems. Fascinating applica- 
tion n-'e emerged from letting users have their heads in 
developing not only new software, but also new hardware ex- 
tensions. (e.g. Ref. 8.) 

Conclusion 

This discussion has aimed at pointing out vital changes 
nhich have been talcing place in the communications interface 
between computers and their information environment. It was 
:onvenient to make a distinction between the programmer- 
omputer or “instruction interface’’ on the one hand, and the 
iata environment-computer or "data interface’’ on the other, 
rhis. of course, cannot be pushed too far, since the adaptive 
apiihi’ity of computers will lead to many more instances in 
,-h- : he computer’s contact with its data environment will be 
he .jns of altering its program. The programmer or user 
an really be thought of as part of the data environment of 
he computer. This is perhaps a little disturbing, particularly 
• hen one notes that real time computers often have a console 
ack which disables all switches (including the on/off) to pre- 


vent unauthorised interference in their operation. One could 
always pull out the power plug in an emergency, however, thev 
also include circuitry to detect the falling supply voltage. This 
produces a program interrupt to a special routine which 
stores away the contents of all flip-flop registers into the non- 
volatile core memory, closes down the memory power in an 
orderly fashion, then quietly waits for the power failure to 
pass, all ready to take up again where it left off. 
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H. THE ENVIRONMENT 

The task of mechanically producing an edited documem 
divides into two areas: — 

i. The collection, organization and maintenance of the crude 
data of the document:- ~_ 


ii. The specification of the appearance, layout and content of 
any final document. 

Problems associated with the crude data are encountered 
m origination, input, addition, modification and extraction for 
review or final output. 
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SUMMARY 

Thii paper proposes a system which can maintain and 
control an organized but amorphous body of data, and can 
produce from the data strictly controlled output such as edited 
documents. Such a system could be implemented on existing 
equipment, but this paper is concerned more with the design 
of the system than with details of implementation. 

The underlying concepts of queued programming and data 
addressing are discussed and, in consonance with the theme 
of this conference, possible development and application of 
the system is foreshadowed. 

I. INTRODUCTION 

The preparation of manuals, reports and technical books 
involves many time-consuming routine tasks such as com- 
posing, sub-editing, numbering, cross-referencing, and prepara- 
tion of indices, contents and headings. The revision and 
correction of such documents is often an even more complex 
and irritating task. 

This paper was originally intended to define a system under 
which an author prepares only the body of the text merely 
as a series of sentences with embedded control signals denot- 
mg significance nodes such as headings, footings, references, 
cross-references and so on. Revision is thus simply a matter 
of adding to or deleting from the prime text and reprocessing. 
Provision is also made for preparation of a series of related 
documents from a single prime text. 

A search of related literature revealed that the problem 
had already been solved. 1 However, many improvements and 
generalizations can be made to existing systems. The litera- 
ture also disclosed the existence of many related problems in 
which a large body of loosely organized data must be main- 
tained and utilized. The existence of a large body of un- 
co-ordinated computer applications then poses a problem in 
synthesis and rationalization. The volume of existing work in 
this area indicates the need, the justification, for attempting 
to gather text processing applications under one system of 
processing. 

Hence this paper proposes a text processing system and 
describes the document generation process as it might be 
carried out by such a system. 


Problems associated with a final document are encnim 
in the specification of the layout and content, and the • 
tion of supplementary data such as contents, indices' 
references and page numbers. ’ 

The processing system must accept both crude data 
instructions for the processing of that data. The data • 
characteristically be quite amorphous, simply a sfrinn - 
characters, and hence instructions must be intimatelv ® 
ciated with the data both in meaning and physical nres 
tion. The instructions will be processed when the do 
processed. Qa 

Document generation is not the only application of 
nature. Similarities may be discerned in the areas of 
setting, photo-composing, computer assisted instm 
numerically controlled machine tools, D.P. system sune 
simulation, and in many other areas. ■ 


A general data processing system philosophy ca„ ■ 
designed to cope with all such applications, where the 
tion between program and data has disappeared. The tvnw 
programming required is termed “queued programmin' 
this paper, and it is a purpose of this paper to prono 
form of queued programming. 

Queued programming (where data and program haverf 
same status) must be distinguished from stored progr,— 
(where the program in main memory runs the data 1 , 
out) although a stored program processing self-d 
records implements a primitive form of queued progra 
A queued programming system may be interpretively 
mented by a stored program, but the two concepts 
distinct. 

A queued programming system can be described fro 
aspects, equipment and processors. 

I. The Equipment -iy: 

The equipment will typically comprise a central 
device with associated data storage, a logging device, 
storage of one or more types, one or more input devi 
one or more output devices, organized as shown in 
which indicates the flow of data between compone: 

A variant configuration shown in Figure 2 indie- 
the functions of data manipulation and data utiliz^fi 
be physically separated. 

Table I gives example of possible equipment com 
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2. The Processors 

The control device or devices will typically operate under 
control of a number of stored programs called processors 
which will be fetched (or initiated) and executed under 
control of a supervisor stored program. A possible complex 
of processors is illustrated in Figure 3, which indicates the 
conceptual flow of data (and queued program) between 
processors. 

Figure 3 also indicates a classification of processors accord- 
rng to the flow of data through them. Table II gives examples 
or possible processors under each classification. 

3. The Language 

The instructions which specify the processing to be carried 
out on data entering into, residing within, and departing from 
the system, are themselves part of that data. Such instructions 
torm queued programs” which may be accessed and executed 
by the processors. 

It is of considerable importance that all processors of the 
system have a common language syntax, for much the same 
reasons justifying a common traffic code for a community. 
This is not to say that all processors should have a common 
vocabulary. In fact, it is the vocabulary which defines the 
Processor. However, all processors should have access to 
common facilities, for example, library storage, in the 
same way. 

The majority of the description which follows is intended 
to give some idea of a proposed language syntax. The lan- 
guage is described in broad scope, but allows simple sub-setting 
tor early implementation. Some of the features may need 
extension, reduction, modification, addition or elimination, 
according to the vicissitudes of implementation. 


DATA TO /FROM 
TERMINALS 


PIG. 3. - QUEUED P R OGRAM PROCESSORS WITH DATA FLOW 

HI. THE LIBRARY 

~Die central theme of the queued program system is the 
maintenance and utilization of the textual data of the system 
Hence it is appropriate to describe the nature of the data and 
its organization before describing the processing of the data. 

1. The Content of the Data 

The data of the system are basically strings of characters 
coded according to the character set of the system. The strings 
are regarded as having a preferred direction, and so each has 
a beginning and an end. 

The nature of the minimum character set is displayed in 
Appendix XI. 1, where descriptive names are given to certain 
classes of characters. Data entering the system may have the 


character set coded in any way, but if it differs from «t/ 
system coding it must present a key prefixing the data iT 
specify the recoding to be carried out. Sk 

2. The Structure of the Data 

The data has two .main levels of structure, general ana 
local, as shown in Figure 4. General structure is definZa' 
metaphorically in terms of libraries and books, which are 
main components of the data. Local structure is defiiW ' 
locally by the data itself. nne<1 : 

3. General Structure 

Within the system of library storage, each independent 
physical unit of storage (for example, each reel of maenei^ ‘ 
tape) is called a library and is identified by a name. Svstem ‘ 
input data may be used as a library when accessed bv an 
input processor. Library data may be dumped on a printed 
by simple transcription provided the printer is identified bv»s 
library name. The association of a device with a library name 
is an operator responsibility, external to the queued program 

The data in each library may be divided into a number ofi 
books, each identified within its library by a name. . 

4. Local Structure 

The data within each book is segmented into two basic 
kinds of sub-strings, statements and text sub-strings. A state- ■ 
ment begins with a single trigger character and continues' 
through the body of the statement to the next ter minate,. 
(refer Appendix XI. 1). A text substring is data between (wo • 
statements. A text string is a statement and its immediately 
following text substring. # BEGIN. This sentence is a' teat 
substring since it has a statement both immediately in front ’ 
and immediately behind. # END. 7 | 

The body of a statement may be subdivided by commas " ; 
mto elements. The first such element, which precedes the ■ ’ 
first comma when present, is called the label. The label is 
used to define the local structure of the data. 

Local structure is of three kinds, as shown by Figure 4® * 
Marking is used to name a text string. The heirarchy is usediM 
to subdivide data at a number of levels to enable referenced 
to data by counting. The concept is quite like the hierarchy . 
of words within sentences within paragraphs within chapters It; 
and so on. Classification is used to enable text strings, and ' 
substrings to be grouped and referenced by class. - tiyi SiEi 
In the following data #3A+2. P#-j-3;+4B,Q. 

4C2. R, three text strings are shown named A, B and C.’® 
turn. A and C have text substrings P and R'. Statement B has 
two elements, a label and an operand Q. Text string C si gnpffig i 
the beginning of the second section at heirarchy level 2 within 
the current level 3. Text string A is classified under 2 r I B-’fl 
under 2, 3 and 4, but text string C is classified under 
not under 2 or 4. , -~.HiSs8i§lp 

5. Referencing the Data 

The purpose of structuring the data is to allow it to beef 
conveniently referenced. The structure described above showi^< 
provision for specification by name, by counting and by clasSCHfe 
It remains to show how the provision can be used. , r! f 

Data is referenced through operands, which are elements' 
of a statement other than the label. The possibilities fo/A 
specification in an operand are shown in Figure 5, but' al© 
these possibilities cannot be described here. Jm 

If the data is to be addressed a locality must be established®®* 
This locality established, a scan may be specified. The scatyif 
may identify a text string or two points defining the beginningSp 
and end of the data addressed. For example, with the dat5||? 
shown as illustration above, the following operands, if usetfiS 
in the immediately fallowing context, would address' ’) th^^P 
data shown. 


OPERAND 

DATA 

* — A 

# 3 A -f- 2. P 

* — A — /C <4> <0-2> 

#+3+4B,Q.R-fij 

* — A+l(l) 

#-f3-f4B,Q. 

*— A + B 

#-i-3+4B,Q. 

* — A<0> 

p 

* — A&/ + B — 

p 

* — A&/‘#’ — 








MARK 


CONDITION 

EXPRESSION 


TERM 


GOVERNING 


RESULTING 


CONDITION 

NAME 


^NDITION CONDITIO 
SYMBOL NAME 


I se examples of data reference show also where a + 
lay be elided . whep no ambiguity is introduced. 

rv. THE STATEMENTS 

ued program statements are accessed and executed by 
cessor in sequence, much as stored programs are 
iced. The elements of a queued program statement are 
■ to the elements of a symbolic stored program, being 
in turn, label, verb and operands. 

label defines the local structure of the data, and its 
s described above under that heading. 

Verb 

verb is an operand and can take most of the forms of 
>erand (see Figure 5). A literal numeric verb is the 
erb form of absolute meaning to any processor. A 
lie verb may- be defined within the queued program, 
dress verb specifies that the addressed data is to be 
:d in lieu of the current statement Locality specifica- 
1 the addressed data refer to the locality of the current 
:nt. 

rands 

meaning applied to operands depends largely on the 
Df the associated verb. Hence, when describing par- 
queued program processors, it is necessary to discuss 
le verbs recognized by the processor and the signifi- 
pfe-cance of the operands to such verbs. 

. .1 4. Conditions 

' ’I Any element of a statement may be prefixed by governing 
: i; condition expressions, and suffixed by resulting condition 
expressions (see Fig. 6). 

;t %T The resulting condition specification causes conditions to be 
set by name according to the successful or not use of the 
v .. 1 element during execution of the statement. Such conditions 
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can then be used to subsequently govern the use of prefixed 
elements. . 

For example, the resulting condition of. any element will 
depend on the recognition of the verb by the accessing pro- 
cessor. The resulting condition of an operand will also depend 
on the successful negotiation of the governing condition and 
. access of addressed data. 

Condition symbols are used for certain conditions defined 
for each processor and which are automatically set. 

5. The Processor Vocabularies 

In the following several sections, the vocabularies appro- 
priate to the supervisor and several processors are summarily 
described. 

Two points should be considered. Firstly, the vocabularies 
are simple but the power rests mainly in the! scope of the 
operands and conditions. Secondly, allowance is made for 
simple vocabulary extension by addition to the verb list. 

V. SUPERVISOR STATEMENTS 

Certain statements of overall significance must be recog- 
mzed by all processors, which is tantamount to being executed 
by the supervisor program. However, the supervisor will 
probably be required to keep more than one processor going 
at any one time, and so it must execute these supervisor 
statements independently' for each processor. A supervisor 
vocabulary is displayed in Table III. 

1. Housekeeping 

Verbs 0, 1. and 2 are provided for general purposes. It 
should be noticed that verb 1, in conjunction with the general 
provisions for character set definition, provides virtual language 
independence. 

The logging function might well be extended to allow 
accounting for system usage. 

2. Queued Program Sequencing 

It has already been explained that address verbs effect 
remote execution. Certain literal verbs also change processor 
execution sequence. The DO verb can cause a number of 
remote statements to be repetitively executed. The CALL, 
FIX and RETURN verbs provide subroutine facilities. The 
GO verb allows non-reflex changes of sequence. The ON 
verb sets up conditional trapping. 


<statement-aqoress/ r 1 

ELEMENT- NUMBERS 1 

EXTERNAL 

LIBRARY 

FORMAL ELEMENTS *ubraay name* book name 

O- DATA ADDRESSED ( 

I “ EXTERNAL 

T - TEXT SUBSTRI NG BO P K 

* *IOOK NAME 


CURRENT 

STATEMENT 


CONDITION EXPRESSIONS. 
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The DATA verb is distinctive in that it is effected from 
the operand stream rather than from the instruction stream. 

3. Initiation and Termination of Processors 

The START verb will initiate the operation of a processor 
and provide a starting point for its queued program sequen- 
cing. Further parameters may be required, for example, in a 
responsive application the terminal to be serviced may be 
specified. The STOP verb can terminate the operation of a 
processor from within its own sequence. 

4. ‘On’ Statements 

The ON statement, in effect, sets up a subroutine or sub- 
routines to be called when the governing condition is set on. 
Entry conditions for each subroutine will usually be set for 
access by a FIX statement, and will usually comprise such 
operands as address of ON statement, address of statement 
provoking the entry and address of data causing the entry. 
Release of control by a subroutine will usually be effected by 
a RETURN statement. 


OPERANDS 


Ref. 

Suggested 

Seq. 

Usual 


No. 

Name 

No. 

Form 

Meaning 

0 

(null) 

2--- 

any 

for condition evalua- 
tion or labelling 

1 

VERB 

even 

number 

verb reference 
number(s) 



odd 

name 

verb name defined 

2 

LOG 

any 

any 

output to logging device 

5 

DO 

2 

literal 

repetition factor 



3--- 

address 

statements to be 
executed 

6 

CALL 

2 

address 

1st statement of 
subroutine 



3--- 

any 

parameters 

7 

FIX 

2--- 

any 

to receive parameters 
operands are default 
values 

8 

RETURN 



return from subroutine 

9 

GO 

2 

address 

next statement in 
sequence 



3--- 

any 

parameters 

10 

ON 

2--- 

address 

must have governing 
condition; defines trap- 
ping address 

11 

DATA 

2--- 

address 

recognized in data 
stream as signifying 
data continuation 




null 

data stream return 

15 

START 

2 

name 

processor identification 



3 

address 

starting point 



4--- 

any 

parameters 

16 

STOP 

2--- 

name 

processor identification 




null 

current processor 


Table HI. — Supervisor Statements 

5. Subroutines 

Formal subroutines may be given control directly by a 
CALL statement or indirectly under the direction of an ON 
statement To return control reflexively on completion of 
the subroutine, a RETURN statement is issued. 

On entry to a subroutine by either of these methods or 
when simply entered by a GO statement, parametric operands 
may be passed, explicitly by a CALL or GO, implicitly other- 
wise. A FIX statement can be used, in effect, to act as a 
named model of the entering statement so that elements of 
the entering statement can be addressed as though the FIX 
statement were the entering statement. When a subroutine is 
entered under the direction of an ON statement, a notional 


CALL statement is postulated for a FIX to model and para- 
meters describing the circumstances of entry are passed ’ 
through its operands. Any operands written to a FIX state- 
ment are taken in default of a corresponding parameter being 
supplied. * 

Entry to a processor through a START statement is 

to subroutine entry by CALL, but the processor entered tak 
independent control. 

VI. INPUT AND OUTPUT STATEMENTS 

The input/output processor vocabulary given in Table IV is 
a quite basic one, and more verbs may be required to enable 
special handling and control of particular devices, for example, 
graphic entry or display devices. Nevertheless, statements 
using such a vocabulary are very powerful by virtue of the 
addressing structure implicit in their operands. : • 

The description in the sub-sections below relates to input 
processors, but also applies to output processors with appro- 
priate changes to the wording. 

y. 


OPERANDS 


Ref Suggested Seq. 

No. Name No. 

Translation 

20 SPECIAL even 

odd 

21 DIGITS 2 

22 LETTERS 2 

23 CHANGE even 

odd 

24 CHECK 2 


Transcription 

30 FILL 

31 EMPTY 

32 FEED 


number 

actual 

actual 

actual 

address 

address 

name 

(name) 

♦name 
address - 

address 

♦name 


SYMBOL 


TIME OF 
EFFECT 


-♦name 


-*name*name 

*name*name 

-‘text’ 


data access 


before translation 


Meaning 


internal coding • . 

external coding I 

.. . ~~yMM H 

external coding : 
external coding ' ’ 

‘ •' 

internal coding j 
external coding y 

left comparand y .jjs*- 
right comparand ( |£' 

criterion y , jja 

(result name) 

input data " g 
buffer area 

buffer area h‘~ 

output data ’jag 

input data 

output data ' ag- 


MEANING -'f 

library or device : y! 
undefined 

library or device data 
terminated /-Traj* 
book not defined 

book data terminated 

... , •, ■' H 

specified text 

encountered 'i 

specified text _ ,.’J| 

encountered 


— hierarchy (count) before „ 

& hierarchy (count) after „ 

hierarchy (count) „ buffering 


specified amount 
transmitted h 

specified amount . 
transmitted . : 

specified amount j 
transmitted 


Table IV. — Input Output Statements and Condition Symnojj 
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1 ;"i,. Functioning of Devices Sjr , . 

i- , ....An input processor acts as an intermediary between a 
iflevtoe or devices (or books in a library) and another processor- 
I ‘ . or processors. As a special case, an input processor may feed . 
ftflBa ircctly to an output processor for device to device transcrip-. ' 
I - (Jon within the system. r 

Ppievices themselves are addressed by conventional names 
llSSl 1 *^ library names) defined externally. An input processor 
j.-jf Stakes i one or more streams of data and produces, after 
^^gjirbcessing, one' or more other streams of data. All data 
l^^gtdnng a system must pass through an input processor (see 
IMKSgSte- ^)- Data brought in by an input processor is fed 
i directly to another processor. 

; : 

I % Data Transcription 

p/Oata may be fed straight through anjnput processor under 
fc|jjfcontrol of a FEED statement. In this case translation is 
jt^carried out as the data passes through. 

j|i Data may be fed into the processor and into a buffer under 
FH-L statement, and fed out of the processor by 
QljjSnn EMPTY statement. For an input processor, translation is 
ig&gaaied out while the buffer is being filled. 

S. ‘S 3; Translation 

■B^gTranslation is specified through statements using verbs 20 
p«;t0 24. of Table IV. It is not within the scope of this paper to 
^•-"discuss the detailed operation of such statements, but it 
should be remembered that the supervisor verbs of Table III 
can be used in all processors. Hence, dynamic control of 
f t and format is applied within a processor by use 

fesaaffl ON statements m conjunction with resulting conditions 
HRmpbed to the data . transcription verbs. Hence, the transfer 
©gsm data can be interrupted, permanently or temporarily, on 
ptj^d^a-dependent conditions, to allow modification of translation 
fitg^les °t alteration (addition, deletion, rearrangement) of 
| Jdata in the stream or buffer. 

| 4. Operation 

Mi in P ut Processor is initiated by a START statement 
I 'Viuch may specify a starting point within the data of the 
Wp®” °r at an input device, in which case the queued 
gjSfcprogram for the processor comes in with the data. 

error t . ai, d manual servicing is carried out without 
{ . - ettect on the sequencing of the queued program. How- 
I f ver \ special conditions such as undefined devices or books 
^Bgnunation of input, are handled much as any other condition.’ 

vn. library statements 

-^Library statements are used to manipulate and control the 
: : .S Yl ,““. rce ® of tbe library. Table V shows possible verbs and 
significance of their operands. 


^^••jLtST aatement enabte certain basic data to be extracted 
£ S m the i,bra 7' The LI ST verb is exceptional in 
£ • a dev * ce ls , specified as the destination for the list, the 
Ve „l™ S £ Dt dlreCt y t0 the device without the need for inter- 
'■% mavT by ° utput Processor. Hence, a LIST statement 
, , y be used to dump any library data onto a printer. 

, ™I ECT statement enables conventional keyword pro- 
tection to be applied to devices and data. P 

2. Data Moving 

ghe^ MpVE differs from the COPY only in that data 

ifism^ a a L s S rf L mo X ed ’ l e -> deleted, from its source after 
moved, while the COPY does not have this effect. 

evervw£ AN s ^ teme u nt specifies a COPY to be carried out 
is satisfied 6 ^ SCa " eXtent that fte scanning operand 

extent 8 ^ If' 4 may J be deleted by specifying data of zero 
*Petifvi™ or f co P‘ ed - Data may be inserted by 

data of zero extent - Otherwise, a replace- 
of target data by source data is carried out. 


VERB 

Ref. Suggested Seq. 
No. Name No. 

Housekeeping 
50 | LIST 2 


51 DEFINE ) 2 - 

52 delete; 

53 PROTECT 2 


Data Moving 
60 ! MOVE 


61 | COPY 


62 SCAN 


Meaning 


address destination for list 
null list of libraries and de- 

vices 

lib. add. list of books in library 
book. add. list of labels in book 

various adding, deleting, merg- 
ing, renaming books, 
libraries, devices 

actual keyword to be used as 
j subscript to device, lib- 
rary or book 

literal type of protection 

address protected data 


any ; data to be moved 

address : targets for move 

any i data to be copied 

address I targets for copy 

address j extent to be scanned 
any j scan to be performed 

any ! data to be copied 


Table V. — Library Statement. 

VIO. DOCUMENT GENERATION 

The process of document generation may be used as an 
illustrative queued program application processor. In one 
torm or another, this application has already been imple- 
mented and used. 1 ' 12 These implementations may thus be 
used tor guidance in design and comparison in evaluation of 
a queued program processor. 

The processor described below is designed for use with 
present day coded character input and line printer output. The 
vocabularies may be simply and consistently extended if 
necessary, to use more sophisticated devices such as displays 
and plotters. * 1 

Document generation may be regarded as a two stage 
operation. The first stage is the raw data input, manipulation 
and revision. The second stage is the production of the docu- 
ment from the raw data. 

1. Input and Revision 

The facilities already described for input and library pro- 
cessing will cater for raw data input, manipulation and 
^' SI ° n ' J npU f Ca " b£ , recoded ’ statements can be inserted, 
data can be reformatted and organized by the input processor, 
and brought under control of the system as a book in a 
bbr , a " y , 0n , ce ln . tbe library, it can be updated, transcribed, 
modified and copied m any detail by the library processor. 

2. Document Generation Facilities 

The following list indicates some of the functions required 
of a document generator to produce from raw data a docu- 
ment such as this paper. 

Line selection and formatting 

Contents and index generation. 

Free format data plus tables and figures. 

Cross-references. 

Citations and footnotes. 

Page formatting and numbering 
multiple columns, 
parallel text. 
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Allowance for paste-in diagrams. 

Headings and footings. 

Justification and hyphenation. 

Typographical control. 

3. Document Generation Processors 

It is in the nature of the problem that the queued program 
be mingled with the document data, since the actions of 
the processor must be closely synchronized with the data it is 
processing. Hence, for the most part, the document data will 
be the text substring attached to a statement, even if the' 
statement has only the label element for naming or organizing 
the text substring. 

The document generation process is very complex, so it is 
best effected by a number of processors working in concatena- 
tion. This renders implementation simpler and creates inter- 
mediate files which can be kept and manipulated to achieve a 
variety of effects. The phases may be nominated as follows: — 

A. Line selection. 

B. Pagination. 

C. Justification. 

D. Typographies. 

The data will pass from phase to phase to be ultimately 
ejected onto, say, a line printer by the typographies phase, 
which phase is only an amplified output processor. Statements 
may drop through as part of the data to be executed when, 
encountered and recognized by a processor and to be pruned 
by feeding only class zero (text-substring) data out of the 
output processor. 

For simple document generation, one or more of the pro- 
cessor phases may be bypassed. 

In the following sections, each processor phase is broadly 
described. In the immediately following section, however, the 
subject of processor variables is discussed because it is relevant 
to each phase. 

4. Processor Variables 

The control of variables by the processor is essential for 
text and page numbering and referencing and is used in all 
three phases of document generation. Table VI shows the 
verbs used for these functions, which may be found useful in 
many other processors. 

Use of Variables 

The most usual use of variables will be where their values 
are SET in an ON-controlled subroutine (for example, ON 
hierarchy during line selection or ON page end during 
pagination). The value may then be inserted into current 
text with a BE statement, or inserted into a SET statement 
operand for use in a later phase to allow forward reference 
from text already encountered. 


VERB 

OPERANDS j 

Ref. | Suggested 
No. ! Name 

Seq. 

No. 

Usual 

Form 

Meaning 

100 

SET 

even 

odd 

symbolic 

literal 

name of variable 
new value or modifi- 
cation 

101 

UNSET 

2--- 

symbolic 

variable to be no 
longer recognized 

© 

/ 

PLACE 

2 

3--- 

symbolic 

address 

name of variable 
destination for value 

103 

BE 

2--- 

actual 

data to be filed over 
this statement 

104 

WATCH 

2 

odd 

even 

symbolic 

literal 

name 

(name) 

variable to be watched 

comparand 

criterion 

(result name) 


Table VI.— Processor Variable Statements. 


Set Statements ’.-3* 

A SET statement notifies the current processor of an initia- i. 
tion or modification to a variable. If the variable has not 
previously (during the current processor execution) been SET, 
then a new variable will be added to the process. !§ 

If the setting value is unsigned, then it replaces the previous 
value. If the sign and value are numeric, then an appropriate 
arithmetic modification is made to the variable. The sign may Iff 
be a prefix or suffix in which case a numeric setting value 
specifies right or left truncation by count, otherwise a right If 
or left concatenation of value. ... 

A setting value operand may be signed or unsigned sym-f« 
bolic, so that values may be transferred between variables and i 
elementary calculations performed. 

Place Statements 

A PLACE statement simply specifies the transfer of a ; 
variable value into text. 

BE Statements - 

The BE statement is a device for inclusion of variable 
values in text. When an operand is symbolic, the operand is ’■ 
replaced by the actual value of the variable named, if and 
only if the variable has a value. The BE statement is peculiar . 
in that, when the last remaining symbolic operand is evaluated - 
by a processor, the statement structure is removed and the 
values of all operands left as ordinary text. 

Watch Statements 

As any variable is modified, its value may be monitori 
and resulting conditions set if the monitoring has been set up 
by a WATCH statement. This enables, for example, excejgg 
tional values or runaway counts to be detected. 

5. Line Selection - f:iai 

The process of line selection is basically a transcription o 
data with segregation by class, evaluation of text-directei 
hierarchy and generation of line-directed hierarchy. The data' 
is transcribed from the queued program statements and their' 
text substrings as they are accessed by the line selection// 1“ j 
processor. Specific line selection verbs are summarized irtt??sf 



Table VII. 

Data Transfer _ . ij 

As source data is accessed, the label is examined for classifi-^*^ 
cation and the data is transcribed under direction of current 
data transfer instructions, which apply a special classification 
into lines (99) and footnotes (98) to the transcribed data Ojjl 
Since data may be classified into more than one group, several £££? 
copies of the source data may be transcribed. 

Data may be transcribed into separate books as raw datt^ 
for contents, indices, bibliographies and citations to be mefgeaSBH 
back later, or transcribed into subsequent source text to be 
later encountered in sequence, or transcribed into already;^, 
transcribed data for the use of subsequent phases. 

Line Control 

The transcription of data by the line selection processor is i 
controlled in broad detail by data transfer statements^ 

(1 above) but the format of transcription is directed by line 
control statements. The transcribed data is segmented into 
lines in a type of hierarchy. The size of a line ..and. tfie 
portion of it available for data is specified by its current” 
WIDTH statement. 1 f 

If tabs have been set by TAB statements, data of different- 
classes may be selectively directed to specific places within’ a- 
line, and a line is then considered filled when' any attempt 
is made to overwrite data already placed in the line. ' ; 

The line selection processor must distinguish between data 
which will end up part of the document — and other data 
such as statements, because only in this way can it tell when 
a line has been filled. For this reason, modification of data 
after line selection must be carefully considered for its effect 
on the content of a line. . 

Lines of data may be generated by horizontal rule 
(HRULE) statements, including blank fines. Specific data, 
may be repeated in specific line positions by vertical rul^ 
(VRULE) statements. 

Use of ON Statements _ 

By appropriate ON statements, the advent of hierarchy 
changes, reclassification and special text may be detected, 
and used to modify the transcription being carried out. B tf 
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n a 
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iau 

iata 

hen 

iata 

Tect 

rule 

iata 

rule 


4* 


VERB 

OPERANDS 


m 

.1 Suggested 

Seq. 

Usual 



I No 


No. 

Form 

Meaning 

1 

Data Transfer 




%• 

Hi 

LINES 1 

even 

numeric 

data classes to be 


FTNOTES 

;0./ ‘ ■' 


transferred during fine 

§ 

112 

PASS 

odd 

address 

selection 

destination 

It 

60 

MOVE 




1 

61 

COPY 




1 

Line Control 




. 

120 

WIDTH 

even 

numeric 

line width and data 


pr ! 




classes 


p 

-* 

odd 

numeric 

indentations 


121 

TAB 

even 

numeric 

tab positions — centre, 



?>- . ■■■ 



left or right justifica- 


* ^ > 

' 

m 


odd 

numeric 

tion 

data classes for tab 


.. 




position 





null 

remove tab 


Data Generation 





• . ■ 

HRULE 

2 

numeric 

number of fines to be 

E 

Hr 

- ■ 



generated 

1 


•Wf. 


null 

finish current line 

J 

!■ -f 


odd 

numeric 

repetitions 




even 

actual 

data to be used for 


if 

*■': ‘ 



ruling 


131 

VRULE 

even 

numeric 

Une position for ver- 


■ • T 




tical rule 

- 

;VC 


odd 

actual 

data to be used for 

-• 


t . 



ruling 

- 

- 


Ai"- 


null 

terminate rule 


Table VII. — Line Selection Statements. 

means document chapter and verse may be numbered 
d headed, statements for subsequent processors may be 
erted, cross-references may be effected, footnotes may be 
hfied, special processes and interpretation may be initiated, 
nd so on. 

i Pagination 

• ^ The Pagination process is basically a transcription of data 
utto a virtual page whose characteristics are controlled by 
queued programming as the data are being filled in. Specific 
pagination verbs are summarized in Table VIII. 

" Data Transfer 

lin?* 6 , main p0rtJ0n of data transcribed is preclassed by the 
; une selection processor into ‘lines’ and ‘footnotes’. As a 

’IWv page 1S beu >g filled, ‘fines’ are filled in serially from 
Iri op , of the Page or column, while ‘footnotes’ are filled in 
i" e bottom, pushing up previous ‘footnotes’. 
ftl *l? rther .,i iala classes may be selected for headings or 
™ongs. The sequence of page filling is headings — body — 

f Th ? completion of a page is triggered by the 

mpieti°n of its body. Headings and footings are defined 
no^cumuJauveJy. The encountering of heading or footing 
overrides previous data in the same class. 

• ^5® Control 

BaSm .P age control verbs are used to define or vary the 
SPArnS? of any page being filled m- The HEIGHT and 
‘ page ° Verbs govern the overa, l vertical layout of the 


.VERB 


OPERANDS 

Ref. 

No. 

Suggested 

Name 

Seq. 

No. 

Usual 

Form 

Meaning 

Data Transfer 




150 

151 

152 

BODY ] 
HEAD j 
FOOT j 

even 

odd 

numeric 

address 

data classes to be 
transferred during 
pagination, 
data destination 

60 

MOVE 




61 

COPY 




Page Control 




160 

HEIGHT 

even 

numeric 

data classes 



odd 

numeric 

maximum Une count 

161 

SPACING 

even 

numeric 

data classes 



odd 

numeric 

interline spacing 

162 

ALIGN 

even 

numeric 

data classes 



odd 

numeric 

alignment position 
centre, left or right 

163 

FRAME 

even 

numeric 

data classes 



odd 

numeric 

i 

frame size 
fixed or moving 


Table VIII. — Pagination Statements. 


The ALIGN verb controls the way fines are filled into the 
page and its control is specific to each data class. By means 
of this verb, multiple column layouts, parallel text, table and 
figure placement and vertical alignment are specified. Further 
fane control can be exerted by the FRAME verb, which can 

r - to specify imperatively or tentatively that a section 
of data is to be placed entirely within one page. Imperative 
framing can be used for tables and figures. Tentative framing 
can be used, for example, for paragraph control to prevent 
isolated lines of paragraphs from appearing at the top or 
bottom of a page. 

The Use of ON Statements 

ON statements are used in pagination, in particular to pict 
the changes from page to page. This enables page numbering, 
the inclusion of full page figures or tables and the switching 
of formats between left side and right side pages. 

To use page number cross-references and indices, PLACE 
statements can set up a page number value for evaluation by, 
say, a BE statement during a subsequent phase of processing. 
7. Justification 

At first glance, justification would appear better done as 
part of pagination. However, the process of justification and 
its corollary of hyphenation may be output dependent, may 
be impossible until page references set up during pagination 
have been evaluated, and wifi be a fairly complex process, 
anyway, requiring heavy use of system facilities. 

When separated, it is apparent that the process will rely 
on page control data passed down from pagination, so that 
the progression of data within the page can be determined. 
Justification Control 

The verb JUSTIFY (see Table IX) is used to control the 
degree of justification to be carried out. It should be remem- 
bered that, firstly, approximate justification has already been 
carried out by the fine selection process and that, secondly, 
complete justification may in any case be unnecessary. 

Certain control information may be passed to the justifica- 
tion algorithm, such as characters (PERIOD), which may be 
followed by any number of blanks; (COMMA), which mav 
be preceded or followed by a blank; (GARNISH), which 
may be deleted, or (SPLIT), which may terminate a fine. 
Use of such conventions within a text can markedly improve 
justification. In addition, synonyms may be supplied to assist 
justification. For example: — 
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VERB 

OPERANDS 

Ref. 

Suggested 

Seq. 

Usual 


No. 

Name 

No. 

Form 

Meaning 

170 

JUSTIFY 

even 

numeric 

data classes 


- 

odd 

numeric 

tolerance 

171 

SYNONYM 

even 

actual 

synonym 



odd 

actual 

pairs 

172 

PERIOD 

2 

actual 

end of sentence 

173 

COMMA 

2--- 

actual 

punctuation 

174 

GARNISH 

2--- 

actual 

redundancy 

175 

SPLIT 

2--- 

actual 

hyphen 

ISO 

HYPHEN 

9 

actual 

dictionary entry 


Table IX. — Justification Statements. 

and ‘and’. 

Hyphenation 

If a line cannot be exactly justified, then hyphenation may 
be carried out. A hyphenation vocabulary may be main- 
tained by HYPHEN statements. 

8. Typographies 

Certain statements directed at obtaining particular effects 
with an output printer may be recognised by a special purpose 
output processor. 

The verbs shown in Table X illustrate a few of the possi- 
bilities. What is possible, and how it is possible, will depend 
on the printing facilities. SUBSCRIPT and SUPERSCRIPT 
may be possible, at least for digits, within the character set 
and implemented by translation, or it may be possible by 
special spacing. BOLD may be implemented by printing in 
the same spot more than once. 


ssS* 

Ref. 

No. 

Suggested 

Name 


200 

| UNDERLINE 





201 | OVERLINE 

202 i BOLD 

203 SUBSCRIPT 

204 SUPERSCRIPT 

205 OVERPRINT 


206 CAPS 

207 SMALLS 

208 INITIALS 

209 STET 


OPERANDS 

Usual 

Form Meaning 

actual data to be under- 
lined 

actual data to be overlined 
actual data printed bold 
actual subscript data 
actual superscript data 

actual sets of data to be 
printed one over the 
other 

null initiate capitals mode 
null initiate normal mode 
null initial capitals mode 
actual suspend translation 


Table X.- — Typographical Statements. 

The verbs CAPS, SMALLS, INI TIALS are aimed at specify- 
ing translation of single case text for a two case printer. 

In using any verbs implemented for an output processor, 
the ability of the VERB statement (Table HI) to enable one 
verb name to invoke more than one action should be very 
useful in simplifying queued programs. 


9. Review 

The document generation language outlined above is at 
preliminary design level, and the description is intended h! 
suggest and define rather than explain. The capabilities inTv 
tended may be more fully appreciated after a study of existing- 
document generation programs, particularly TEXT 90. 1 How! 
ever, to guide comparison of the queued programming tech ' 
niques with more conventional techniques, certain of th - 
described features should be emphasized, since they art! 
central to the aim of simplification and rationalization of th«- 
application and provide a base for extension of document • 
generation to use of more sophisticated output devices. 
Instruction Sequencing 

The instructions may occur contiguously with the data Thev i 
may be accessed sequentially as the document data i, 
accessed, and non-sequentially as certain preset condition, 
arise. 

Data Organization 

Data within the system can be organized by labelling in a 
number of different simultaneous ways to considerable dentlr 
of detail. Data within the system can be accessed by address 
mg or encounter to any level required. 

Coding and Vocabulary . 

TV,. • . . 


. 1116 system can accept and mampulate instructions and 
data, using any definable character set, and can control it. - f 
lay own vocabulary. 

.in- . T 

IX. OTHER APPLICATION PROCESSORS iJpS.'i.j 

Any application in which processing instructions arelffial 
mately associated with their object data may be suitableifuL 
queued program implementation. Some of these applications 
3se are considered briefly in the paragraphs below: ‘ VMBi 

1. Extended Library Functions 
The library processing functions already described (Table 

22 V), when used with appropriate operands, allow selective filing 

f t and retrieval of information. By allowing actual literal sub- 

set elements (as Figure 5) as part of the label of a statement. 

■ y specialized verbs or processors may be defined for filing 
tn retrieving and sorting by direct-addressing of the label com-’ 
bmed with either data or address in the text sub-string;.’ Ugf? 

2. Permuted Index Generation 
A processor which generates a permuted index is iuef_ 

- both in As own right for production of KWIC indices.'and 
as an adjunct to document generation.* 1 

The application is particularly suited to queued program 
ming since, by these means, dynamic control 'can be exercise* 
r- over stop and go words, synonyms, text separation, depth 6 

indexing, prefix suppression and cross-referencing. 

3. Responsive AppUcations 

d Several approaches to responsive applications are possibl 

depending on the effects required. The ter minal, may. eaCu 
be serviced by an input processor which directs the input to, 
tlm appropriate processor in, say, a data filing and retrieval* 

The application processor may, on the other hand, directly! 
communicate with a terminal in a computer assis te d in- 
e struction application using verbs such as ACCEPT or 1 

e PRESENT. 30 ’ 31 , 

The closest coupling possible would be when the supervikofsi 
takes the data queued program and text together, straightil 
from the terminal, and executes it directly. 
s 4. Calculating Facilities ~ 

The provision of calculating facilities may be regarded ajwj 
e a special case of a responsive application, but the faalitie*!§ 

required will determine the nature of the process. For simpkXj| 
desk calculator capability, supervisor implemented variable 

— handling verbs (Table VI) will suffice. A special processor, 
may extend these functions as a responsive application.** Fty-T 
more powerful facilities, a queued programming system ma^S 
be used as an intermediary to operate a computing system.®|! 

y- a conversational mode, superimposing extended library fadfip| 
ties on a more usual QUIKTRAN system.” js||| 

r, 5. Computing System Operation 

te A queued programming system may be used to opent&^jpi 

y computing system, by either supplying input, processing output. A 
or both.” In supplying input, the queued programming 
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3 perform many of the more indirect services of a con- 
pnal operating system, by managing data files, controlling 
regression, collecting data, manipulating source programs, 
■iding object programs and so on, most of which functions 
nowadays specified by a quasi-queued programming lan- 
rge. - In processing output, a document generator could 
jute queued program generated amply by the computing 

| effect, this suggestion envisages a two-phase data pro- 
ng' system in which text processing is handled by a queued 
ram machine while arithmetic and logical processing is 
ited by a stored program machine. 33 Given that a reason- 
sttividing line can be discerned, the two machines can 
individually designed for operation to its function rather 
fe grafting text processing facilities onto a computing 
ie to achieve a similar effect - 

X. CONCLUSIONS 

paper describes a queued programming system and a 

Oment generator ‘operating within the system. The paper 
’ritten with a spirit of speculation in line with the theme 
his conference. The system described is prototypical, and 
6rfld be developed and modified during implementation. 

ustification 

^queued programming system may' be justified by trends 
[programs and computing machinery and by the often stated 
Ted for new thinking in application of computers. 

Articles and papers describing non-numerical applications 
Joiind : in data processing literature, but their diversity is 
[tuie bewildering. So is the effort which must be expended in 
aplementing this diversity. Were a common theme applicable 
i a large number of these applications, this effort could be 
'uced through standardization of techniques, data, program 
ents, training and equipment. 

jmputer hardware has become more sophisticated, but 
e‘ sophistication is not of use to the ordinary computer user, 
"iipment such as associative and bulk memory, direct access 
storage devices, data scanning file processors, special 
^ jse coupled processors and fixed program processors may 
;of direct use in a queued program system, and their in- 
ing use will render them more economical, 
aginative predictions for future data processing are often 
de through the analogy that by the year, say 1980, com- 
ing power will be available as electrical power now is — 
S>a public utility. Some equivalent of queued programming 
* ■' prerequisite for public facility. 

Possible Development 

queued programming does develop, three lines would 
be followed. 

: queued programming language would develop. Hope- 
& the main design principles may be retained or embedded 
extension. The syntax described for a queued pro- 
ig language bears an evident resemblance to a symbolic 
assembly language in its ‘label, verb, operands’ format. This 
at simplifies the processor organization, but leaves room 
I ' Tor development on higher level language models. 

The repertoire of queued program applications would 
extend and the vocabulary of each processor would also 
. expand as dictated by experience in use. 

' The processors, described implicitly as conventionally 
implemented, would be microprogram implemented. 

| 3, Feasibility 

1 . The facilities outlined could, with considerable restrictions, 

, provided by a large stored program complex. Most of the 
jyfig|mfities are already provided, in one form or another, piece- 
, lnea l across a large number of programs. 

. However, the feasibility must be considered at two levels. 
; . a glorious queued programming system feasible? Is the 
implementation of standards for queued programming feasible? 
.The answer to the first question is probably — not yet, 
“tough it would be fascinating to try. 

. ■> The answer to the second question might well be an 
^operative yes. Programs implementing typical queued pro- 
- sram applications are proliferating, and early recognition of 


a unifying principle and acceptance of appropriate standards 
could significantly assist the development and synthesis of 
applications and equipment. 

XI. APPENDICES 

1. Syntax Tables 

The syntax tables of this appendix are in a preliminary 
state, being neither complete nor rigorous. 

The first table displays the basic character set and allocates 
lower case reference letters to each class of characters. The 
remaining tables define syntactic units in terms of characters 
(reference letters) or other syntactic units (reference numbers) 
with the following metalanguage operators:— 
juxtaposition the juxtaposed units are used in sequence 
/ the separated units are exclusively used 

() the enclosed term is a syntactic unit 

[ ] the enclosed term is a unit and is optionally used 

. . . the preceding unit may be repeatedly used 

A the following unit is excluded within the preced- 

ing unit. 


Name 

Ref. 

Definition 

Where used 

null 

trigger 

a 

b 

# 

74, 75 

digit 

c 

0/1 / — /8/9 

1 

letter 

d 

A/B/— /Y/Z 

10, 53 

plus sign 

e 

4_ 

i 

2, 3, 11, 24, 44 

minus sign 

f 

— 

2, 3, 11, 24, 44 

data sign 

g 

& 

3, 45 

name sign 

h 

* 

2, 11, 24, 47, 51 

text sign 

j 

* 

15, 41, 59 

operand sign 

k 

» 

73 

inch terminator 

p 

(blank) 

74 

excl. terminator 

q 

. 

74 

left bracket 

r 

( 

20, 25, 42 

right bracket 

s 

) 

20, 21, 25, 42 

left limit 

t 

< 

40, 53 

right limit 

u 

> 

40, 53 

separator 

V 

/ 

2, 46, 53, 70-72 

any 

z 

b/c/ ---/u/v 

15, 21, 75 


Name 

Ref. 

Definition 

| Where used 

integer 

1 

c[l] 

1,2,3,21,31,35, 




42,58 

arithmetic integer 

2 

(e/f/h/v) 1 

57 

class integer 

3 

(e/f/g) 1 

12,30 

name 

10 

d [10] 

10, 11,21,22,32, 




36,49,51,56 

condition modifier 

11 

[e/h] [f] 10 

20 

class selector 

12 

3 [12] 

12, 40 

literal text 

15 

((zA j)/jj) [15] 

15,41,59 

Condition expressions 



resulting condition 

20 

r 1 1 s [20] 

20, 70-72 

condition symbol 

21 

((zAs) [21]) A 

21,23 



(1/10) 


condition name 

22 

[f] 10 

23 

condition term 

23 

21/22 

25 

condition prefix 

24 

e/h 

25 

governing cond. 

25 

r 23 [24(23/25)] 

25, 70-72 



s [25] 



14/2/10 


*i«ti*r* * 





sec; : 
genera i 
one y. I 
regula 


This 
purer ti 
ore dis 
copabil 


In r< 

univers 

b { 

the stu< t 

the cot 
- classes 
examin 
of pap 
concuri 
the prc 
may tr 
to the 
table v 
possible , 
In Y : 
' attsntic 
the ex 
to be : 
and a: 
specific j 
the mi 


structii 
and w 
includt 

i able ti 


At 

(or a ! 
scienci I 
week | 
week ‘ 
period I 
sports | 
lag u : 
which 


Name 

Ref. 

Definition | 

Where used 

Labels 




class 

30 

3 

33 

hierarch v 

31 

1 

33,42 

mark 

32 

10 

33,43 

label base 

33 

(30/31/32/33) A 

33,70 



(31 31) 


Verbs 


' 


actual verb 

35 

1 

38 

symbolic verb 

36 

10 

38 

indirect verb 

37 

55 

38 

verb base 

38 

35/36/37 

71 

Operand terms 




class selection 

40 

t 12 u [40] 

40,55 

literal scan 

41 

j 15 j 

46 

heirarchv scan 

42 

31 rls 

46 

hierarchy scan 

43 

32 

46 

scan prefix 

44 

e/f 

45,46 

scan start 

45 

44/g 

46 

scan specification 

46 

[45][v]44 (4 1 /42/43 ) 55 

1 

Addresses 




current statement 

47 

h 

48,50 

current book 

48 

47 47 

49, 50 

external book 

49 

48 10 

50 

local library 

50 

47/48/49 

52 

external library 

51 

h lOh 10 

52 

direct locality 

52 

50/51 

54 

indirect locality 

53 

t 55 v [1/d] u 

54 

locality 

54 

52/53 

55 

address 

55 

54 [46...] [40] 

37,61 

Literals 




symbolic 

56 

10 

60 

incremental 

57 

2 [57] 

57, 58, 60 

numeric 

58 

1 [57] 

60 

actual 

59 

j 15 j 

60 

literal 

60 

56/57/58/59 

61 

operand base 

61 

55/60 

72 

Statements -- • 




label 

70 

25 33 20 [v 70] 

70,73 

verb 

71 

25 38 20 [v 71] 

71,73 

operand 

72 

25 61 20 [v 72] 

72,73 

statement sub-string 

73 

[70][k[71][k 

74 



[72]]...] 


statement 

74 

b 73 (p/q) 

76 

text sub-string 

75 

((z A b)/bb)75 

75,76 

string 

76 

74 [75] 



2. REFERENCES 

The following references do not comprise an exhaustive bibliography , 
but represent a selection from the material available to the author. The 
references are grouped approximately according to their area of 
relevance, though considerable overlap is evident. Many of the references 
themselves include extensive bibliographies. 

The following conventions have been used in the reference list: — 

i. Page references to journals have been abbreviated as, for example, 
V12N6P32, meaning in Volume 12, issue Number 6, at Page 32. 

ii. CACM stands for Communications of the Association for Com- 
puting Machinery. . . ... 

iiL In the case of IBM manuals of indefinite authorship, the form 
number has been given in place of the author name. 


I "! r0 J UC C° n Sekora 'er al. (June. 1965) “TEXT 90” — Share General 
Program Library — 7090IBM0022. 

2. C. J. Duncan (1964) “Look! No Hands!" — The Penrose Annual, 

1964 — Lund Humphries. ' _ ~ 

3. I. Heller (Sept.. 1964) “A Proposed System for the Collection, 
Correction and Rearrangement of Large Masses of Data” — Literary 
Data Processing Conference Proceedings — IBM 320-0906. 

4. R. E. Bargmann et al. (May, 1964) “Applied Research Program 
Aerospace Intelligence Data System” — IBM Research. Report 
RC1194. 


5. M. Kochen (Mar., 1963) “Some Ideas and Pertinent Resea 
Toward an Automated Encyclopaedic Information Service” 
Confidential) IBM Research Report RC921. ., 

Text Processing: 


6. M. P Barnett, K. L. Kelley (April, 1963) “Computer Editing of 
Verbal Texts” — American Documentation V14N2P99. 

7. M. V. Wilkes (Oct., 1964) “A Programmer’s Utility Filing System 

— The Computer Journal V7N3P180. ■ ida&j. 

8. J. L. Bennett. D. C. Clarke (May. 1964) “A Program to Aid? 
the Editing of Machine-Readable Text” — IBM Research Rent 
RJ299. 

9. L. F. Buckland (Feb., 1965) “The Recording of Library of Congress 
Bibliographical Data in Machine Form” — Council on Library- 
Resources, Inc. 

rjnr.nmenr Generation: ' :,< -5 


Resources, Inc. 

Document Generation: 

See particularly 1 and 2 above. 

10. J. T. Carleton et al. (Aug., 1964) “A Fortran Extension to Fac 
tate Proposal Preparation” — IEEE Transactions on Electronic Com^ 1 
puters V13N4P456. 

11 . J. S. Dibble (Dec., 1964) “Paper and Program Documentation 
Editor” — IBM Program Library 1401-01.4.193. 

12. H20-0185 “1440/1460 Administrative Terminal System — Terming 
Operator’s Manual”. 

13. W. A. Danielson (Aug., 1963) “A Computer Program for Editing 7 , 
the News”— CACM V6N8P487. 

14. M. P. Barnett et al. (April, 1964) “Computer Generation of PhotoSB 
composing Control Tapes, Part II — The PC6 System” — American 5 
Documentation V15N2P115. 

Input and Output: 

15. R. George (Mar., 1965) “Tabular Input of Data” — CACM 
V8N3P182. 

16. J. L. Bennett (Sept.. 1963) “Procedure for Using a Flexowriter to 
Copy Text” — IBM Research Report RJ268. 

17. J. L. Bennett, A. C. Swain (Sept., 1963) “A System for Transcrib- 
ing Text for Information Processing” — IBM Research Rr-— 
RJ269. 

18. C. J. Shaw (May, 1964) "On Declaring Arbitrarily Coded Alp; 
bets” — CACM V7N5P289. 

19. M. Klerer, J. May (May, 1964) “An Experiment in a UserOri 

Computer System” — CACM V7N5P290. ■-'% 

20. B. Perry, M. L. Mendelsohn (May, 1964) “Picture Generation wi 
a Standard Line Printer” — CACM V7N5P311. 

21. A. Hassitt (June, 1964) “Design and Implementation of a Gerii 
Purpose Input Routine” — CACM V7N6P350. 

22. J, B. Goodenough (Feb., 1965) “A Lightpen-Controlled Program 

Online Data Analysis” — CACM V8N2P130. -Vt 

23. R. F. Simmons (Jan., 1965) “Answering English Questions 
Computer — A Survey” — CACM V8N1P53. 

Other Queued Programming: 

24. W. D. Climenson (Mar., 1963) “RECOL — A Retrieval C 

Language" — CACM V6N3P117. 9S 

25. M. Grems (Jan., 1962) “A Survey of Languages and Systems.fi 
Information Retrieval” — CACM V5N1P43. 

26. C28-65J9 “Operating System Job Control Language”. 

27. H 20-0078 “LBM1620 Drafting System”. ' „ 

28. S. A. Brown et al. (Nov., 1963) “A Description of the.; i 

Language” — CACM V6N11P649. . • r 

29. H20-8180 “PERT COST II Program for the 7090”. 

30. C24-3384 “1401/1440/1460 Operating Systems — Computer 

Instrucuon — Author and Proctor Manual”. ' _ 

31. H. D. Huskey (1961) “Automatic Computers and Teaching Machines 
in “Programmed Learning and Computer-based Instruction” — Pr 
ceedings of the Conference on Application of Digital Computers 
Automated Instruction — Wiley. 

32. C28-6800 “IBM7040/7044 Quiktran User’s Guide”. 

33. H20-0 185-0 “1440/1460 A.T.S. Terminal Operator’s Manual” — ‘ . 
Computer”, pp. 54-59. 

34. C28-6772 “Autochart Programming System”. 

35. H. E. Anderson (Jan., 1965) “Automated Plotting of Flowc 
on a Small Computer” — CACM V8N1P38. 

Queued Programming Hardware: 

36. A. J. Melbourne, J. M. Pugmire (April, 1965) “A Small Comput 

for the Direct Processing of Fortran Statements” — The Comput 
Journal V8N1P24. . _ 

37. A. P. Mullery (Aug., 1964) “A Procedure Oriented Machine 
guage” — IEEE Transactions on Electronic Computers V13N4P 

38. S. G. Campbell et al. (1962) “A Non-arithmetical System Ex 
sion” — Chapter 17 of “Planning a Computer System” — Edit 
W. Buchholz- McGraw-Hill. 

39. C28-6382 “7090-7040 Direct Couple Operating System — Progr 
mer’s Guide”. 

40. A26-5988 “System/360 Component Descriptions — 2841 Control UmC 

Future Development: ' ■ 

41. H. P. Luhn (Sept., 1959) “Potentialities of Auto-encoding Scienti 
Literature” — Information Retrieval Systems Conference — IB 
E20-8040. 

42. C. N. Mooers (Jan., 1963) “The Reactive Typewriter Program 

CACM V6N1P48. . 

43. J. Rose (Oct., 1965) “Effective Automation” — Science Jou 
V1N8P81. 

Syntax: - 

44. W. H. Burkhardt (May, 1965) “Metalanguage and Syntax Specifii 

tion” — CACM V8N5P304. - 

45. K. E. Iverson (Oct., 1964) “A Method of Syntax Specification 

CACM V7N10P588. -• 

46. (Mar., 1965) “Criteria for Standardization of a Pro: 

ming Language” — The Computer Bulletin V8N4P149. 

Late Reference: Of major significance to the subject: 

47. C. N. Mooers, L. P. Deutsch (Aug.. 1965) “TRAC, A Text Handlm 

Language” — -Proceedings of the ,20th National Conference , of 
Association for Computing Machinery pp. 229-246. ., 


14/2/11 v 









Vx> 


| (> /‘ H§ s °~f f 


I The Utilization Of 
|| Keyboard Display 
Consoles in A 
ionventional Operating 
Environment 


By R. H. KERR and G. KAROLY 
Control Data Australia Pty. Limited, 
122 Empire Circuit, 
Yarralumla, A.C.T. 


ABSTRACT 


S&w de “ r!pti0 " is S'r 6 " of * he keyboard display consoles 
1*°^, have bee " attached to the CONTROL DATA 3600 
Computer at the C.S.I.R.O. Computing Research Section, 
^hp. manner in which these displays have been integrated 
^With high speed drums, enabling them to be used in an 

B ^economic manner concurrently with the normal work load, 
«|f described in some detail. Also described is a program 
which enables documents to be created and edited at the 
®^display consoles. 


m INTRODUCTION 

riSTDm 1 in this P a P er was carried out on a 

,ONTROL DATA 3600 Computer installed at" the C.S.I.R.O. 
computing Research Section in Canberra, and represents a 
Mmon of.tw° year’s effort by a combined C.S.I.R.O. and Con- 
|9l| Data Australia group! 2. The authors acknowledge the 
tontnbution made by all members of the group, but particu- 
lar, acknowledgement for that portion of the work described in 
fe„Pw Per ls due W p - A. Collings and I. D. Wadham. 
gyvitn_ current emphasis on more direct communication be- 

r, f W.L CO ? PU , ter and ', he USer ’ increasin g use is being made 
at keyboard display consoles and similar devices for peripheral 

fe 0 !, computer systems. A keyboard display console-or 
■|a»spiay for short— consists of a typewriter-like keyboard 
, dlSp ay d fl ce (usually cathode ray screen) on which 
i^tmter R°H- ty i Pe lr by ^ °? erator ’ or Provided by the com- 
' f dls P la >’ ed ln the form of alphanumeric characters 
^^information displayed on the screen is also available as 
E, l? the computer. These displays are well suited to 
" h ‘ Ch requlre q ue stion and answer type “con- 
r communication with a computer. 

WFir* tesetvation systems are probably the best known 
ample Of a class of annlirafinnc invnlinn/r - .• r 


^""catinn i.' u r . — particularly suitable. Another appli- 

’ - Share in WhCn 2 n , Umber o£ users eacb with his own display, 
f en T S -° £ \ lar S e computer to carry out independent 
)M MACS at MLT - is an example of this 
r '‘ WinJ ‘"“r 5 ”' 6 ”’ except that they currently use tele- 
used “ t C ° m P uter 'COn trolled displays have also been 

tion45 , !l lng devices ln "Programmed learning” instruc- 

ocrimi*;.,i - 1116 • above cases the computer is generally fully 

! * >avThe r fi n e ^ la ? g ** consoIes and as sociated tasks. ' 
^■'tan^w 0 ; Computing Research Section recently added 

drum siorL^i^fi; Un ‘ tS and 16 million characters of fast- 
^ drumc l g their computer installation in Canberra. The 
fe rate re ,y olut T “ me of 35 milliseconds and a trans- 

Th* ° f * characters per second. 

IS paper describes the display equipment, the parts of 
•nitorl 2 conremprl wifV» , 


1^^=? with dispIay operaiion ’ and ** 


•'..v, Pa use °f the displays. 

A DESCRIPTION OF THE DISPLAY CONSOLE 

NSiW'-"'- 


'* ; -T u SUB-SYSTEM 

I Data Pui P rv . sub 'S vs,e m contains six modified CONTROL 
210 Display Consoles. The display screen on each con- 


sole can hold 1000 characters in 25 lines of 40 characters enrh 
The typewriter keyboard can be used to type a character anv- 
w-here on the screen, replacing any characters which may 
already be at the positions selected for the type-ins. A marker 
on the screen indicates where the next character may be typed. 
This marker can be moved to any desired position by such 
operations on the keyboard as carriage return, tab, reset to 
top left of page, skip one place forward, backspace and slew 
(continuous movement forward). Thus, it is possible to type 

?n£? gt L ° f 1000 characters and at anytime change any of the 
1000 characters. ’ 

The displays are attached to control equipment -which sets 
up and maintains the contents of the screens independently 
of the computer. This control equipment also allows the 
transfer of information in either direction between the display- 
units and the computer. While a user is viewing or in any 
way altering the contents of a screen there is no requirement 
tor computer intervention, and therefore the computer can 
proceed with other work. An interrupt key is provided to 
enable the user to request service from the computer. In addi- 
tion to this interrupt key there are twelve function keys and 
two toggle switches. The computer can interrogate these kevs 
and switches to determine the service required. In general the 
form of service will depend on the program controlling’ the 
display at the time. 8 

The character set on the displays consists of 63 characters 
and is based on the ALGOL set. The keyboard lavout is 
shown in Fig. 1. ■ 

Other features of these displays are the tab facility, the 
function and toggle keys and the program-controlled indicator 
lamp. These features increase the versatility of the displays 
and make them particularly suitable for a variety of research 
and development work in the field of man/machine com- 
munication. 


Kt 


THE DISPLAY MONITOR 

The monitor system under which the displays operate is 
designed to handle all input/output equipment, with the ex- 
ception of magnetic tapes, in a multiplexed pseudo off-line 
manner. These peripheral operations take place concurrently 
with the execution of a main job. Programs executed from 
the main job stack cannot use the displays. All programs 
which make use of displays are controlled by a display- monitor 
operating under the main monitor. Such programs are called 
Display Programs.” The display monitor bears the same 
relation to Display Programs as the main monitor does to 
programs of the main job stack. A full description of the 
main monitor, which is very similar externally to the Atlas 

conference! I’ ^ ^ found in other P a P ers presented at this 

The main unit of information handled by the system is the 
document . Each document has a name within' the system 
and all initial references to documents are by name. A docu- 
ment may consist of one or more files. Examples of documents 
are: a data file; a source program; a job, i.e. a program to- 
gether with monitor control statements and data files. 

The main factors influencing the design of the display 
monitor were: r ; 

1. It would be uneconomic to tie up the whole installation 
to service six displays. Based on current commercial rates 
the value of time on this installation would be approxi- 
mately S400 per hour. Therefore, if no other work could b c 
done while displays were being used, the time on each 
display w-ould be worth $67 per hour which is unattrac- 
tive. 

2. The installation has the requirement to keep job stack 
processing going continuously to process work for the 
various divisions of C.S.I.R.O., other Government organi- 
sations and University users, both from Canberra and 
other centres. 

The preparation of requests by the display user takes several 
seconds, while their servicing occupies the computer for a 
fraction of a second. Thus display users are able to have 
access to the computer at any time on demand and receive 
service with little or no delay under normal operating con- 
ditions. When the computer is not servicing requests generated 
by the display consoles, it will be executing jobs submitted 
in the normal way (Main Programs). The slow peripheral 
operations (card reading, printing, plotting and card-punching) 
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Fig. 1: Keyboard Layout 

will operate on a time-sharing basis with both the Display 
Programs and the Main Program. Initially the servicing of 
displays is not expected to effect unduly the execution time of 
Main Programs. This is because the display programs initially 
implemented are ones requiring little central processor time. 

The following were the design objectives for the display 
monitor and its interaction with the overall system: 

1. The time lag in servicing the displays should be imper- 
ceptible to the user. 

2. Normal job stack and input/output processing should be 
concurrent with display operation. 

3. All the facilities provided under the standard tape orien- 
ted monitor (SCOPE) 9 should be available to programs in 
the main job stack. In particular, the amount of core 
store available must not be decreased. 

4. The increase in main job execution time due to display 
servicing should be a minimum and the central processor 
time used for display servicing should be separately 
accountable. 

5. A special language should not be necessary for the writ- 
ing of Display Programs. 

When the display sub-system is enabled by the operator, the 
main monitor divides the core store into four areas. These are 
the Main Program Area, the main monitor resident area, the 
Display Program Area and the display monitor resident area. 
The amount of core store available for the Main Program Area 
is the same as is available under the SCOPE monitor, and 
hence the third design criterion is met. The Display Program 
Area is 2000 words and only holds the program for one display 
at a time. All displays use this area in tum when they are 
being serviced. Special drum areas are reserved for each dis- 
play, for the purpose of saving the contents of the Display 
Program Area when it has to be used to service a display 
other than the one last serviced (Fig. 2). 

When a display whose program is not currently in core 
store interrupts and is eligible for service, the main program 
is halted and a core swap takes place. The current contents 
of the display area are written onto the special area on the 
drum allocated to the display last serviced. The drum area 
of the interrupting display is read into core store and then 
the servicing takes place. The average time for this core 
swap is 50 milliseconds, with a maximum of 80 milliseconds. 
This scheme is very similar to the one used by Digital Equip- 
ment Corporations in some of their machines designed for 
multi-user operation. 

As an example of this, consider .the following situation: the 
last Display to be serviced was Display 4, the servicing has 
been completed and the Main Program is in control when 
Display 2 interrupts. When this interrupt occurs the Dis- 
play Program Area still contains the program and data for 
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Drum and Core Store Layout. 

• - 

the operation of Display 4. The sequence of events that now A 
takes place is as follows: 

1. The Main Program is halted and appropriate registers [f 
are stored. 

2. The contents of the Display Program Area are written , ; J 

onto the drum in the area allocated to Display 4. rj; 

3. The contents of drum area for Display 2 are read into 
the Display Program Area. 

4. The “bounds register” is set to confine activities to the J 
Display Program Area and control is passed to the Dys-xjB 
play Program. The display interrupt is serviced with S 
interrupts active; i.e. Display Programs run in exactly.^* 
the same mode as Main Programs. ' 

5. When the display has been serviced control is returned- jSj 
to the Main Program at the point of interruption with ^ 
all registers, including the bounds, restored. 

The above description of the manner in which the display^ 
core area is shared between the displays, describes but one 
function of the display monitor. The following is a list' of 
some of the other situations that the display monitor has toJ|j 
deal with. 

1. To process requests for runs of Display Programs. This® 
includes the loading of such programs and their overlays^® 

Display Programs are prepared by the main loader to operate?® 
in the Display Program Area. They are docutpents held o^® 
the 4mm in the exact form they will have in core duringas 
execution and when one is called it is copied directly into cor^H 
by the display monitor. 

These programs can be written in any of the availably® 
programming languages though in practice, because of. th^K 
small area of core store available for the Display Programs;' fh^Jj 
initial programs have been written in the assembly languagb^lH 

There are certain rules that have to be observed in writit^M 
Display Programs. These rules affect core store allocationJSS 
input/output operations, interrupt servicing routines, Juterfa 
rupt selection and program segmentation. .- 

The core space available is only 2000 words and if thisjjs|| 
exceeded the program is not loaded and a diagnostic is pro-^ 
vided. Display Programs can generally only use the display^ajB 
and drums as input/output devices and effectively all daf|a| 
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locale the document, CIDER notifies the user of this and 
repeats the original request for document identification and 
the action required. If the document can be located, but is in 
use by another program, the console user is given the choice 
of waiting or restarting with another document. 

Next the user is asked to select the means of indicating on 
the screen the end of a logical record of the document. He is 
criven the choice of either accepting the standard end of record 
character or substituting one of his own choice or electing that 
no end of record character be displayed. The last choice 
implies fixed length logical records, and under these circum- 
stances the user is asked to specify how many lines of the 
displav each record will occupy. 

At this point the user is informed that the program is now- 
under function key control and he can proceed to manipulate 
the document bv operating these keys in conjunction with the 
interrupt kev. During such manipulation, the contents of the 
screen are treated as being part of the document, i.e. any 
change made on the screen results in a corresponding change 
in the document. There is one exception to this: the restore 
function is provided to request that the contents of the screen 
as last written by CIDER be re-displayed. This enables the 
user to recover if he has made an error in changing the 
information on the screen. 

Three of the function keys are used to select “page mode”, 
“record mode” or "line mode” for display. These modes deter- 
mine not so much the form of the display, but the minimum 
amount bv which the document can be moved through the 
display screen. This amount is referred to as the "unit of 
display information". In “page mode" the minimum move- 
ment through the screen is the full contents of the display- 
screen- in line mode, it is one line of the display screen; in 
record mode it is one logical record. Regardless of the “mode 
of the display, the line is blank filled beyond the termination 
of each logical record. In both page and line mode all lines 
of the screen will be used but in record mode only complete 
logical records are displayed and therefore there may be blank 
lines at the bottom of the screen. 

Other operations available in “function mode ’ are 

Move Forward, Move Backward , , , _ 

These move the document through the display screen by one 
unit of display information at a time. 

Qplctc 

The unit of display information at the top of the display- 
screen is deleted and ’ the document is moved an appropriate 
amount to refill the screen. 

^The unit of display information at the top of the screen is 
moved off, leaving a blank space for insertions while the Test of 
the contents of the screen remains stationary. 

In “message mode”, apart from replies to direct queries by 
CIDER. initially only a small number of operations have been 
implemented. Some of these control the movement of the 
document, e.g. Skip to End-of-File, Rewind, etc.; others are 
directions to the monitor, e.g. “print"— which results in the 
document being placed in the monitor’s output list for punt- 
ing and “terminate” — indicating to CIDER that the user has 
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finished. The program has been designed to facilitate the 
addition of further operations in message mode and these wi‘ 
be implemented as need arises and effort is available. 

As an example of the use of CIDER, consider the situatio 
where a console user wishes to alter one statement in 
FORTRAN program which already exists as a document on:' 
the drum. He first asks CIDER for the particular document 
and states that he wants to edit it. Since the FORTRAN pro- 
gram is stored in 80 character card images, he may then specify 
a fixed record length of two lines on the display with end o 
record markers omitted. When informed by CIDER that, hi 
is “under function key control" he will probably select pagi 
mode” and move the program through the display screen using 
the “move forward” function until the statement he wishes to 
correct appears on the screen. Having made the desired cor*.Sg 
rection, he can request “message mode” of operation and then, 
ask CIDER to “Skip to End-of-Document”. If he now wants to 
have the program compiled and executed he may request 
CIDER to put the document on the Execution List before he 
terminates the run. The results of the compilation and execu- 
tion will appear with the results of other jobs in the Execu- 
tion List, on whatever medium was specified in t-.e document 
itself. If this results in a drum document being pr 
then it could be inspected from any of the displays. 


CONCLUSION '-.t-hP* 

This work demonstrates that a limited number of displays 
or similar buffered devices can be added to a system operating 
on conventional lines as long as fast random access storage- 
devices are available. The hardware cost, beyond that for th^j 
displav equipment, is small. In the case described, this cost j 
that of 16,000 words of drum store and 2,000 words of co 
store. The main cost, however, is in providing a monitory 
system which allows the displays to be used concurrently wit 
job stack processing. _ TTj 

Matters such as actual response times, possible expansion o 
the number of displays and the programming cost of imple 
menting the display monitor will be discussed at the Confer--:.* 
ence on the basis of operational experience. 

■ 
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A User Machine in a Time-Sharing System 


B. W. LAMPSON, W. W. LICHTENBERGER, member, ieee, and M. W. PIRTLE 


Abstract — This paper describes the design of the computer seen by a 
machine-language programmer in a time-sharing system developed at the 
University of California at Berkeley. Some of the instructions in this machine 
are executed by the hardware, and some are implemented by software. The 
user, however, thinks of them all as part of his machine, a machine having 
extensive and unusual capabilities, many of which might be part of the hard- 
ware of a (considerably more expensive) computer. 

Among the important features of the machine are the arithmetic and 
string manipulation instructions, the very general memory allocation and 
configuration mechanism, and the multiple processes which can be created 
by the program. Facilities are provided for communication among these 
processes and for the control of exceptional conditions. 

The input-output system is capable of handling all of the peripheral 
equipment in a uniform and convenient manner through files having symbolic 
names. Programs can access files belonging to a number of people, but each 
person can protect his own files from unauthorized access by others. 

Some mention is made at various points of the techniques of implementa-. 
tion, but the main emphasis is on the appearance of the user’s machine. 
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Introduction 

A CHARACTERISTIC of a time-sharing system is 
/—A that the computer seen by the user programming in 
machine language differs from that on which the 
system is implemented [1], [2], [6], [10], [11]. In fact, the 
user machine is defined by the combination of the time- 
sharing hardware running in user mode and the software 
which controls input-output, deals with iilegai actions which 
may be taken by a user's program, and provides various 
other services. If the .hardware is arranged in such a way 
that calls on the system have the same form as the hardware 
instructions of the machine [7], then the distinction becomes 
irrelevant to the user ; he simply programs a machine with an 
unusual and powerful instruction set which relieves him of 
many of the problems of conventional machine-language 
programming [8], [9]. 

In a time-sharing system which has been developed by 
and for the use of members of Project Genie at the Uni- 
versity of California at Berkeley [7], the user machine has a 
number of interesting characteristics. The computer in this 
system is an SDS 930, a 24 bit, fixed-point machine with one 
index register, multi-level indirect .addressing, a 14 bit 
address field, and 32 thousand words of 1.75 /is memory in 
two independent modules. Figure 1 shows the basic con- 
figuration of equipment. The memory is interleaved between 
the two modules so that processing and drum transfers 
may occur simultaneously. A detailed description, of the 
various hardware modifications of the computer and their 
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Fig. 1. Configuration of equipment. 


implications for the performance of the overall system has 
been given in a previous paper [7]. 

Briefly, these modifications include the addition of moni- 
tor and user modes in which, for user mode, the execution 
of a class of instructions is prevented and replaced by a trap 
to a system routine. The protection from unauthorized 
access to memory has been subsumed in an address mapping 
scheme: both the 16 384 words addressable by a user pro- 
gram (logical addresses) and the 32 768 words of actual . 
core memory- (physical addresses) have been divided into 
2048-word pages. A set of eight six-bit hardware registers . 
defines a map from the logical address space to the real 
memory by specifying the real page which is to correspond 
to each of the user’s logical pages. Implicit in this scheme is , 
the capability of marking each of the user's pages as un- 
assigned or read-only, so that any attempt to access such a ) 
page improperly will result in a trap. ' 

All memory references in user mode are mapped. In 
monitor mode, all memory references are normally ab- 
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tem routine thus invoked ma.y ta.ke n purcimeter trom tne 
word addressed by the SYSPOP. since its address field is not 
interpreted by the hardware. The routine will address the 
parameter indirectly through location zero and. because of 
the bit marking the contents of location zero as having come 
from user mode, the user map will be applied to the re- 
mainder ot the address indirection. All calls on the system 
which are not inadvertent are made in this way. 

A monitor mode program gets into user mode by trans- 
ferrins to an address with mapping specified. This means, 
among other things, that a SYSPOP can return to the user 
program simply by branching indirect through location 
zero. 

As the above discussion has perhaps indicated, the mode- 
changing arrangements are very clean and permit rapid 
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Fig. 2. The hardware memory map. (a) Relation between virtual and 
real memorv for a typical map. 1 b) Construction ol a real memory 
address. 


solute. It is possible, however, with any instruction in moni- 
tor mode, or even within a chain of indirect addressing, to 
specify use of the user map. Furthermore, in monitor mode 
the top 4096 words are mapped through two additional 
registers called the monitor map. The mapping process is 
illustrated in Fig. 2. 

Another significant hardware modification is the mecha- 
nism for going between modes. Once the machine is in user 


Basic Features of the Machine 

A user in the Berkeley time-sharing system, working at 
what he thinks of as the hardware language level, has at his 
disposal a machine with a configuration and capability 
which can be conveniently controlled by the execution of 
machine instruction sequences. Its simplest configuration 
is very similar to that of a standard medium-sized computer. 
In this configuration, the machine possesses the standard 
930 complement of arithmetic and logic instructions and. in 
addition, a set of software interpreted monitor and executive 
instructions. The latter instructions, which will be dis- 
cussed more fully in the following, do rather complex 
input-output of many different kinds, perform many 
frequently used table lookup and string, processing func- 
tions. implement floating point operations, and provide for 
the creation of more complex machine configurations. Some 
examples of the instructions available are: 


O C? 

mode, it can get to monitor mode under three circum- 


stances : 


1) if a hardware interrupt occurs, 

2) if a trap is generated by the user program as outlined, 
and, 

3) if an instruction with a particular configuration of two 

bits is executed. Such an instruction is called a system 
programmed operator (SYSPOP). 

In case 3), the six-bit operation field is used to select bne of 
64 locations in absolute core. The current address of the 
instruction is put into absolute location zero as a subroutine 
lin k, the indirect address bit of this link word is set, and an- 
other bit is set, marking the memory location in the link 
word as having come from user-mapped memory. The sys- 


1) Load A, B, or X (index) registers from memory or 
store any of the registers. Indexing and indirect ad- 
dressing are available on these and almost all other 
instructions. Double word load and store are also 
available. 

2) The normal complement of fixed-point arithmetic and 
logic operations. 

3) Skips on various arithmetic and logic conditions. 

4) Floating point arithmetic and input-output. The latter 
is in free format or in the equivalent of Fortran E or F 
format. 

5) Input a character from a teletype or write a block of 

arbitrary length on a drum file. . 

6) Look up a string in a hash-coded table and obtain its 

position in the table. 

7) Create a new process and start it running concurrently 
with the present one at a specified point. 

8) Redefine the memory of the machine to include a por- 
tion of that which is also being used by another pro- 
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It should be emphasized that, although many of these 
instructions are software interpreted, their format is identi- 
cal to the standard machine instruction format, with the 
exception of the one bit which specifies a system interpreted 
instruction. Since the system interpretation of these in- 
structions is completely invisible to the machine user, and 
since these instructions do have the standard machine in- 
struction format, the user and his program make no distinc- 
tion between hardware and software interpreted instruc- 
tions. 

Some of the possible 192 operation codes are not legal 
in the user machine. Included in this category are those 
hardware instructions which would halt the machine or 
interfere with the input-output if allowed to execute, and 
those software interpreted instructions which attempt to 
do things which are forbidden to the program. Attempted 
execution ot one of these instructions will result in an 
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Fig. 3. Layout of virtual memory for a typical process. 
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illegal instruction violation. The effect of an illegal instruc- 
tion violation is described later. 


Memory Configuration 

The memory size and organization of the machine is 
specified by an appropriate sequence of instructions. For 
example, the user may specify a machine which has 6K of 
memory with addresses trom 0 to 13777 s : alternatively, he 
may specify that the 6K should include addresses 0 to 3777 8 , 
14000 8 to 17777 8 . and 34000 8 to 37777 s . The user may also 
specify the size and configuration of the machine’s sec- 
ondary storage and, to a considerable extent, the structure 
of its input-output system. A full discussion of this capa- 
bility will be deferred to a later section. 

The next few paragraphs discuss the mechanism by which 
the user’s program may specify its memory size and organi- 
zation. This mechanism, known as the process map to dis- 
tinguish it trom the hardware memory address mapping, 
uses a (software) mapping register consisting of eight 6-bit 
bytes, one byte for each ot the eight 2K blocks addressable 
by the 14 bit address fieid of an instruction. Each of these 
bytes either is 0 or addresses one of the 63 words in a table 
called the private memory table (PMT). Each user has his 
own private memory table. An entry in this table provides 
information about a particular 2K block of memory. The 
block may be either local to the user or it may be shared. If 
the bock is local, the entry gives information about whether 
it is currently in core or on the drum. This information is 
important to the system but need not concern the user. If 
the block is shared, its PMT entry points to an entry in an- 
other table called the shared memory table (SMT). Entries 
in this table describe blocks of memory which are shared by 
several users. Such blocks may contain invariant programs 
and constants, in which case they will be marked as read- 
only, or they may contain arbitrary data which is being pro- 
cessed by programs belonging to two different users. 

A possible arrangement of logical or virtual memory for a 
process is shown in Fig. 3. The nature of each page has been 
noted in the picture of the virtual memory; this information 
can also be obtained by taking the corresponding byte of the 
map and looking at the PMT entry specified by that byte. 
The figure shows a large amount of shared memory, which 


suggests that the process might be a compilation, sharing 
the code for the compiler with other processes translating 
programs written in the same source language. Virtual 
pages one and two might hold tables and temporary storage 
which are unique to each separate compilation. Note that, 
although the flexibility of the map allows any block of code 
or data to appear anywhere in the virtual memory, it is cer-. 
tainly not true that a program can run regardless of which 
pages it is in. In particular, if it contains references to itself, 
such as branch instructions, then it must run in the same 
virtual pages into which it was loaded. 

Two instructions are provided which permit the user to 
read and modify his process map. The ability to read the 
process mapping registers permits the user to obtain the 
current memory assignment, and the ability to write the 
registers permits him to reassign memory in any way which 
suits his fancy. The system naturally checks each new map 
as it is established to ensure that the process is not attempt- 
ing to obtain unauthorized access to memory which does 
not belong to it. 

When the user’s process is initiated, it is assigned only 
enough memory to contain the program data as initially 
loaded. For instance, if the program and constants occupy 
3000 s words, two blocks, say blocks 0 and 1, will be assigned, 
At this point, the first two bytes of the process mapping 
register will be nonzero; the others will be zero. When the 
program runs, it may address memory outside of the first 
4K. If it does, and if the user has specified a machine size 
larger than 4K, a new block of memory will be assigned to 
him which makes the formerly illegal reference legal. In 
this way, the user’s process may obtain more memory. In 
fact, it may easily obtain more than 16K. of memory simply 
by addressing 16K, reading and preserving the process 
mapping register, setting it with some of the bytes cleared 
to zero, and grabbing some more memory. Of course, only 
16K. can be addressed at one time; this is a limitation im- 
posed by the address field of the machine. 

There is an instruction which allows a process to specify 
the maximum amount of memory which it is allowed to 
have. If it attempts to obtain more than this amount, a 
memory violation will occur. A memorv violation can also ■, 
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pc caused by attempts to transfer into or indirect through 
unassisted memorv. or to store into read-only memory. 
The effect of this violation is similar to the effect of an 
illegal instruction violation and will be discussed. 

The facilities just described are entirely sufficient for pro- 
grams which need to reorganize the machine's memory 
solely for internal purposes. In many cases, however, the 
program wishes to obtain access to memory' blocks which 
have been created by the system or by other programs. For 
example, there may be a package of mathematical and utility 
routines in the system which the program would like to use. 
To accommodate this requirement, there is an instruction 
which establishes a relationship between a name and a cer- 
tain process mapping function. This instruction moves the 
PMT entries for the blocks addressed by the specified pro- 
cess mapping function into the .shared memory table so 
that they are generally accessible to all users. Once this 
correspondence has been established, there is another in- 
struction which allows a different user to deliver the name 
ttnd obtain in return the associated process map. This in- 
struction will, if necessary, make new entries in the second 
user’s PMT. Various subsystems and programs of general 
interest have names permanently asigned to them by the 

system. 

The user machine thus makes it possible for a number of 
Processes belonging to independent users to run with 
memory which is an arbitrary combination of blocks local 
t0 each individual process, blocks shared between several 
Processes, and blocks permanently available in the system. 
A complex configuration is sketched in Fig. 4. Process 1.1 
*as shown in more detail in Fig. 3. Each box represents a 
Process, and the numbers within represent the eight map 
Mes. The arrows between processes show the process hier- 



archy, which is discussed in the next section. Note that 
the PMT’s belong to the users, not to the processes. 

From the above discussion, it is apparent that the user 
can manipulate the machine memory configuration to per- 
form simple memory overlays, to change data bases, or to 
perform other more complex tasks requiring memory re- 
configuration. For example, the use of common routines is 
greatly facilitated, since it is necessary only to adjust the 
process map so that lj memory references internal and ex- 
ternal to the common routine are correct, and 2) the memory 
area in which the routine resides is read-only. In the simplest 
case, in which the common routine and the data base fit into 
16K of memory, the map is initially established and remains 
static throughout the execution of the routine. In other cases 
where the routine and data base do not fit into 16K, or 
where several common routines are concurrently employed, 
it may be necessary to make frequent adjustment to . the 
map during execution. 

Multiple Processes 

An important feature of the user machine allows the 
user program, which in the current context will be referred 
to as the controlling process, to establish one or more sub- 
sidiary processes. With a few minor exceptions, to be dis- 
cussed, each subsidiary process has the same status as the 
controlling process. Thus, it may in turn establish a sub- 
sidiary process. It is therefore apparent that the user 
machine is in fact a muiti-processing machine. The original 
suggestion which gave rise to this capability was made by 
Conway [3]; more recently the Multics system has in- 
cluded a multi-process capability [4], [5], [13]. 

A process is the logical environment for the execution of a 
program, as contrasted to the physical environment, which 
is a hardware processor. It is defined by the information 
which is required for the program to run; this information 
is called the state vector. To create a new process, a given 
process executes an instruction which has arguments 
specifying the state vector of the new process. This state 
vector includes the program counter, the central registers, 
and the process map. The new process may have a memory 
configuration which is the same as, or completely different 
from, that of the originating process. The only constraint 
placed on this memory specification is that the total memory 
available to the multi-process system is limited to 128K by 
the process mapping mechanism, which is common to all 
processes. Each user, of course, has his own 128K. 

This facility was put into the system so that the system 
could control the user processes. It is also of direct value, 
however, for many user processes. The most obvious ex- 
amples are input-output buffering routines, which can 
operate independently of the user’s main program, com- 
municating with it through memory and with interrupts 
(see the following). Whether the operation being buffered 
is large volume output to a disc or teletype requests for in- 
formation about the progress of a running program, the 
degree of flexibility afforded by multiple processes far ex- 
ceeds anything which could have been built into the input- 
output system. Furthermore, the overhead is very low: an 
additional process requires about 15 words ot core, and 
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process switching takes about 1 ms under favorable condi- 
tions. There are numerous other examples of the value of 
multiple processes; most, unfortunately, are too complex to 
be briefly explained. 

A process may create a number of subsidiary processes, 
each of which is independent of the others and equivalent 
to them from the point of view of the originating process. 
Figure 4 shows two simple multi-process structures, one for 
each of two users. Note that each process has associated 
with it pointers to its controlling process and to one of its 
subsidiary processes. When a process has two immediate 
descendants, as in the case of processes 1 .2 and 1 .3, they are 
chained together on a ring. Thus, three pointers, up, down, 
and ring, suffice to define the process structure completely. 
The up pointers are, of course, redundant, but are con- 
venient for the implementation. The process is identified by 
a process number which is returned by the system when it is 
created. 

A complex structure such as that in Fig. 5 may result from 
the creation of a number of subsidiary processes. The pro- 
cesses in Fig. 5 have been numbered arbitrarily to allow a 
clear description of the way in which the pointers are ar- 
ranged. Note that the user need not be aware of these 
pointers, they are shown here to clarify the manner in 
which the multiple process mechanism is implemented. 

A process may destroy one of its subsidiary processes by 
executing the appropriate instruction. For obvious reasons 
this operation is not legal ii the process being destroyed it- 
self has subsidiary processes. It is possible to find out what 
processes are subsidiary' to any given one; this permits a 
process to destroy an entire tree of sub-processes by reading 
the tree from the top down and destroying it from the bot- 
tom up. 

The operations of creating and destroying processes are 
entirely' separate from those of starting and stopping their 
execution, tor which two more operations are provided. A 
process whose execution has been stopped is said to be 
suspended. 

To assure that these various processes can effectively 
work together on a common task, several means of inter- 
process communication exist. The first allows the con- 
trolling process to obtain the current status of each of its 
subsidiary processes. This status information, which is read 
into a table by the execution of the appropriate system 
instruction, includes the current state vector and operating 
status. The operating status of any process may be 

1) running, 

2) dismissed for input-output, 

3) terminated for memory violation, 

4) terminated for illegal instruction violation, or 

5) terminated by the process itself. 

A second instruction allows the controlling process to 

become dormant until one of its subsidiary processes termi- 
nates. Termination can occur in the following four ways: 

1) because of a memory violation, 

2) because of an illegal instruction violation, 

3) because of self-termination. 
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Fig. 5. Hierarchy of processes 


Interactions described previously provide no method by 
w hich a process can attract the attention of another process 
which is pursuing an independent course. This can be done 
with a program interrupt. Associated with each process is a 
20-bit interrupt mask. If a mask bit is set, the process may, 
under certain conditions (to be described in the following)! 
be interrupted ; i.e., a transfer to a fixed address will be 
simulated. The program will presumably have at this fixed 
address the location of a subroutine capable of dealing with 
the interrupt and returning to the interrupted computation 
afterwards. The mechanism is functionally almost identi- 
cal to many hardware interrupt systems. 

A process may cause an interrupt by delivering the num- 
ber ot the interrupt to the appropriate instruction. The pro- 
cess causing the interrupt continues undisturbed, but the 
nearest process which is either on the same level as the one 
causing the interrupt or above it in the hierarchy of pro- 
cesses, and which has the appropriate interrupt armed, will 
be interrupted. This mechanism provides a very flexible way 
tor processes to interact with each other without wasting 
any time in the testing of flags or similar frivolous ac- 
tivities. 

Interrupts may be caused not only by the explicit action of 
processes, but also by the occurrence of several special 
conditions. The occurrence of a memory violation, at- 
tempted execution of an illegal instruction, an unusual 
input-output condition, the termination of a subsidiary 
process, or the intervention of a user at a console (by push- 
ing a reserved button) all may cause unique interrupts (if 
they have been previously armed). In this way, a process 
may be notified conveniently of any unusual conditions 
associated with other processes, the process itself, or a con- • 
sole user. 

The memory assignment algorithm discussed previously 
is slightly modified in the presence of multiple processes. 
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When a process is activated, one of three options may be 
specified: 

1 ) Assign new memory to the process entirely inde- 
pendently of the controlling process. 

■’■) As ■ -"a no new memory to the process. Any attempt to 
obtain new memory will cause a memory violation. 

X) [f the process attempts to obtain new memory, scan 
upward through the process hierarchy until the top- 
most process is reached. If at any time during this 
scan a process is found for which the address causing 
the trap is legal, propagate the memory assigned to it 
down through the hierarchy to the process causing 
the trap. 

Opt: . :: 3.1 permits a process to be started with a subset of 
memory and later to reacquire some of the memory which 
was not given to it initially. This feature is important be- 
cause the amount of memory assigned to a process influ- 
ences the operating efficiency of the system and thus the 
speed with which it will be able to respond to teletypes or 
other real-time devices. 

The Input-Output System 

The user machine has a straightforward but uncon- 
ventional set of input-output instructions. The primary 
emphasis in the design of these instructions has been to 
make all input-output devices interface identically' with a 
program and to provide as much flexibility in this common 
interface as possible. Two advantages result from this uni- 
formity: it becomes natural to write programs which are 
essentially independent of the environment in which they 
operate, and the implementation of the system is greatly 
simplified. To the user the former point is. of course, the 
important one. 

It has been common, for example, for programs written 
to be controlled from a teletype to be driven instead from a 
file on. let us say. the drum. A command exists which per- 
mits the recognizer for the system command language and 
all of the subsystems to be driven in this way. This device is 
particularly useful for repetitive sequences of program 
assemblies and for background jobs which are run in the 
absence of the user. Output which normally goes to the 
teletype is similarly diverted to user files. Another applica- 
tion of the uniformity of the file system is demonstrated in 
some of the subsystems, notably the assembler and the 
various compilers. The subsystem may request the user to 
specify where he wishes the program listing to be placed. 
The user may choose anything from paper tape to drum to 
his own teletype. In the absence of file uniformity each sub- 
system would require a separate block of code for each 
possibility. In fact, however, the same input-output in- 
structions are used for all cases. 

The input-output instructions communicate with files. 
The system in turn associates files with the various physical 
devices. Programs, for the most part, do not have to account 
for the peculiarities of the various actual devices. Since de- 
vices differ widely in characteristics and behavior, the flexi- 
bility of the operations available on files is clearly critical. 


They must range from single-character input to the output 
of thousands of words. 

A file is opened by giving its name as an argument to the 
appropriate instruction. Programs thus refer to all files 
symbolically, leaving the details of physical location and 
organization to the system. If authorized, a program may 
refer to files belonging to other users by supplying the name 
of the other user as well as the file name. The owner of a 
file determines who is authorized to access it. The reader 
may compare this file naming mechanism with a more 
sophisticated one [12], bearing in mind the fact that file 
names can be of any length and can be manipulated (as 
strings of characters) by the program. 

Access to files is, in general, either sequential or random 
in nature. Some devices (like a keyboard-display or a card 
reader) are purely sequential, while others (like a disk) 
may be either sequentially or randomly accessed. There are 
accordingly two major I, O interfaces to deal with these dif- 
ferent qualities. The interface used in conjunction with a 
given file depends on whether the file was declared to be a 
random or a sequential file. The two major interfaces are 
each broken down into other interfaces, primarily for rea- 
sons of implementation. Although the distinction between 
sequential and random files is great, the subinterfaces are 
not especially visible to the user. 

Sequential Files 

The three instructions CIO (character input-output), 
WIO (word input-output), and BIO (block input-output) 
are used to communicate with a sequential file. Each instruc- 
tion takes as an operand a file number. This number is given 
to the program when it opens a file. At the time of opening a 
file it must be specified whether the file is to be read from or 
written onto. Whether any given device associated with the 
file is character-oriented or word-oriented is unimportant; 
the system takes care- of all necessary character-to-word 
assembly or word-to-character disassembly. 

There are actually three separate, full-duplex physical 
interfaces to devices in the sequential file mechanism. 
Generally, these interfaces are invisible to programs. They 
exist, of course, for reasons of system efficiency and also, 
because of the way in which some devices are used. The 
interfaces are : 

1 ) character-by -character (basically for low-speed, char- 
acter-oriented devices used for man-machine inter- 
action), 

2) buffered block I/O (for medium-speed I/O applica- 
tions), 

3) block I/O directly from user core (for high-speed 
situations). 

It should be pointed out that there is no particular relation 
between these interfaces and the three instructions CIO, 
WIO. and BIO. The interface used in a given situation is a 
function of the device involved and, sometimes, of the 
volume of data to be transmitted, not of the instruction. 

Any interface may be driven by any instruction. 
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Of the three subinterfaces under discussion, the last two 
are straightforward. The character-by-character interface 
is, however, somewhat different and deserves some elabora- 
tion. Devices associated with this interface are generally 
(but not necessarily) used for man-machine interaction. 

onsider the case of a person communicating with a pro- 
gram by means of a keyboard-display (or a teletype). He 
types on the keyboard and the. information is transmitted 
to the computer. The program may wish to make an im- 
mediate response on the display screen. It many cases this 
response will consist of an echo of the same character, so 
t at the user has the feeling of typing directly onto the 
screen (or onto the teleprinter). 

So that input-output can be carried out when the pro- 
gram is not actually in main memory, the character-by- 
c aracter input interface permits programs a choice, of a 
number of echo tables; it further permits programs a choice 
°f grade of service b - v Permitting them to specify whether a 
given character is an attention (or break) character. Thus 
lor example, the program may specify that each character 
typed is to be echoed immediately and that all control 
characters are to result in activation of the program regard- 
less of the number of characters in the input buffer. Alterna- 
tively. the program may specify that no characters are 
echoed and every character is a break character. By chang- 
ing the specification the program can obtain an appropriate 
(and varying) grade of service without putting undue load 
on the system. Figure 6 shows the components of the char- 
acter-by-character interface; responsibility for its opera- 
tion is split between the interrupt routine called when the 
device signals for attention and the routine which processes 
the user's I/O request. 

The advantage ol the lull-duplex, character-by-character 
mode of operation is considerable. The character-bv- 
character capability means that the user can interact with 
his program in the smallest possible unit— the character. 
Furthermore, the full-duplex capability permits, among 
other things 1) the program to substitute characters on 
strings of characters as echoes for those received, 2) the 
keyboard and display to be used simultaneously (as, for 
example, permitting a character typed on a keyboard to 
pre-empt the operation of a process. In the case of typing 
information in during the output of information, a simple 
algorithm prevents the random admixture of characters 
which might otherwise result), and 3) the ready detection of 
transmission errors. 

Instructions are included to enable the state of bo th input 
and output buffers to be sensed and perhaps cleared (dis- 
carding unwanted output or input). Of course, it is possible 
lor a program to use any number of authorized physical 
devices; in particular, this includes those devices used as 
remote consoles. A mechanism is provided to permit output 
which is directed to a given device to be copied on all other 
devices which are output linked to it (and similarly for input). 

This is useful when communication among users is desired 
and in numerous other situations. 

The sequential file has a structure somewhat similar to 
tha t of an ordinary magtape file. It consists of a sequence of 
logical records ot arbitrary length and number. On some 
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devices, such as a card reader or the teletype, a file may have 
on y one logical record. The full generality is available for 
drum files, which are the ones most commonly used. The 
logical record is to be contrasted with the variable length 
p ysical record of magtape or the fixed length record of a 
card. Instructions are provided to insert or delete logical 
records and increase or decrease them in length. Other in- 
structions permit the file to be “positioned” almost in- 
stantaneously to a specified logical record. This gives the 
sequential file greater flexibility than one which is com- 
pletely unaddressable. This flexibility is only possible' of 
course, because the fiie is on a random-access device and , 
the sequential structure is maintained by pointers. The 
implementation is discussed in the following. 

When reading a sequential file, CIO and WIO return cer- 
tain unusual data configurations when thev encounter an 
end of record or end of file, and BIO terminates transmis- 
sion on either of the conditions and returns the address of 
the last word transmitted. In addition, certain flag bits are 
set by the unusual conditions, and an interrupt may be 
caused if it has been armed. 

The implementation of the sequential file scheme for 
auxiliary storage is illustrated in Fig. 7. Information is 
written on the drum in 256-word physical records. The 
locations of these records are kept track of in 64-word index 
blocks containing pointers to the data blocks. For the file 
shown, the first logical record is more than 256 words long 
but ends in the second 256-word block. The second logical 
record fits in the third 256-word block and the third logical 
record— in the 4th data block— is followed by an end of 
file. If a file requires more than 64 index words, additional i 
index blocks are chained together, both forward and back- 
ward. Thus, in order to access information in the file it is 
necessary only to know the location of the first index block. 

It may be worthwhile to point out that all users share the 
same drum. Since the system has complete control over the 
allocation of space on the drum, there is no possibility of un- 
desired interaction among users. 

Available space for new data blocks or index blocks is 
kept track of by a bit table, illustrated in Fig. 8. In the 
figure, each column represents one of the 72 physical bands 
on the drum allocated for the storage of file information. 

Each row represents one of the 64 256-word sectors around 
a band. Each bit in the table thus represents one of the 
460S data blocks available. The bits are set when a block is 
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::. A 8. Bit table for allocation of space on the drum. 


in use and cleared when the block becomes available. Thus, 
if a new data block is required, the system has only to read 
the physical position ot the drum, use this position to index 
in the table, and search a row for the appearance of a 0. 
The column in which a 0 is found indicates the physical 
track on which a block is available. Because of the way the 
row was chosen, this block is immediately accessible. This 
scheme has two advantages over its alternative, which is to 
chain unused blocks together: 

1) It is easy to find a block in an optimum position, using 
the algorithm just described. 

2) No drum operations are required when a new block 
is needed or an old one is to be released. 

It may be preferable to assign the new block so that it be- 
comes accessible immediately after the block last assigned 
for the Tie. This scheme will speed up subsequent reading 
of the file. 

Random Files 

Auxiliary storage files can also be treated as extensions of 
core memory rather than as sequential devices. Such files 
ore called random files. A random file differs from a se- 
quential file in that there is no logical record structure to the 
file and that information is extracted from or written into 
die random file by addressing a specific word or block of 
words. It may be opened like a sequential file; the only 
difference is that it need not be specified as an output or an 
input file. 

Four instructions are used to input and output words and 
blocks of words on a random file. To permit the random 
file to look even more like core memory, an instruction 
tables one of the currently open random files to be 
specified as the secondary memory file. Two instructions. 


Main Memory 

Secondary Memory ! 

i LDA* ADDR j 

1 

LAS ADDR | 

: STA* ADDR | 

SAS ADDR i 

(a) 

Address 

Instruction 

L J 

600 

LAS 1450 j 

1450 

16345 i 

J 

16345 

1234567 i 

Effect: l: 

234567 A 


(b) 

Fis. 9. Load and store form main and secondary memory. 

(a) Instructions, (b) Addressing. 

LAS (load A from secondary memory) and SAS (store A m 
secondarv memory), act like ordinary load and store in- 
structions with one level of indirect addressing (see Fig. 9) 
except, of course, that the data are in a random file instead 
of in core memory. 

Random files are implemented like sequential files except 
that end of record indicators are not meaningful. Although 
as many index blocks are used up as required by the size 
of a random file, only those data blocks which actually con- 
tain information will be attached to a random file. As new 
locations are accessed, new data blocks are attached. 

Subroutine Files 

Whereas it makes little sense to associate, say, a card 
reader with a random file, a sequential file can be associated 
with any physical device in the system. In addition, a 
sequential file may be associated with a subroutine. Such 
a file is called a subroutine file , and the subroutine may thus 
be thousht of as a “nonphysical” device. The subroutine 
file is defined by the address of a subroutine together with 
information indicating whether it is an input or an output 
file and whether it is word or character oriented. An input 
operation from a subroutine file causes the subroutine to 
be called. When it returns, the contents of the A register is 
taken to be the input requested. Correspondingly, an output 
operation causes the subroutine to be called with the word 
or character being output in A. The subroutine is completely 
unrestricted in the kinds of processing it can do. It may do 
further input or output and any amount of computation. 
It may even call itself if it preserves the old return address. 

Recall that for sequential files the system transforms all 
information supplied by the user to the format required by 
the particular file; hence, the requirement that the user, in 
opening a subroutine file, must specify whether the file is to 
be character or word oriented. The system will thereafter do 
all the necessary packing and unpacking. 

Subroutine files are the logical end-product of a desire to 
decouple a program from its environment. Since they can 
do arbitrary computations, they can provide buffers ot any 
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TRYInTTJ^ ^ are SCheme desi S" ed t0 “P'ement an experimental 

IBM System/360, Model 40 time-sharing system will be discussed. The 
concept of a v.rtual system will be introduced which allows up to fifteen 
simultaneous users on the system, each user assuming he has a complete 
hardware-software of his own. The problem of building and interfacing a 64- 

wfinierev.VweT mem0ry “ existing hardware « 
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Introduction - 

T HE advanced technology group at the IBM Pough- 
keepsie Laboratory has designed and built a hard- 
ware configuration for an experimental time-sharing 
system to be used as a research tool at the IBM Cambridge 
Scientific Center. Many multiprogrammed or multiple- 
accessed systems [1 J-[I0] have been built or proposed; 
however, there is much controversy on the organization and 
efficiency of such systems. The goal for this time-sharing 
system is to gather data on the operational 


desired complexity between the assumptions a program has 
made about its environment and the true state of things. In 
act, they make it logically unnecessary to provide an identi- 
cal interface for all the input-output devices attached to the 
system; if uniformity did not exist, it could be simulated 
with the appropriate subroutine files. Considerations of 
convenience and efficiency, of course, militate against such 
an arrangement, but it suggests the power inherent in the 
subroutine file machinery. 
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Summary 

The user machine described was designed to be a flexible 
oundation for development and experimentation in man- 
machine systems. The user has been given the capability 
to establish configurations of multiple processes, and the 
processes have the ability to communicate conveniently 
with each other, with central files, and with peripheral de- 
vices. A given user may, of course, wish only to use a sub- 
system of the general system (e.g., a compiler or a debugging 
routine) for his particular job. In the course of using the sub- 
system, however, he may become dissatisfied with it and 
wish to revise or even rewrite the subsystem. The features 

ot the user machine not only permit this activity but make it 
easier. 
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